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ABSTRACT 

A  process  framework  for  the  front-end  of  product  development  was  developed.  The  framework  covers  the 
process  space  from  an  initial  need  (or  recognition  of  need)  to  the  decision  for  a  product/development 
program  launch.  The  framework  focuses  on  the  activities  required  for  the  development  of  requirements 
needed  for  an  investment  decision.  The  framework  was  developed  through  a  thorough  examination  of  the 
literature  relating  to  product  development  and  addresses  not  only  the  activities  required  to  traverse  the 
front-end,  but  also  metrics  and  a  process  maturity  matrix  by  which  an  organization  can  be  evaluated. 

Using  case  studies  of  the  front-end  processes  of  eight  commercial  organizations  and  eight  military 
organizations  in  addition  to  the  US  Air  Force,  the  framework  was  tested.  All  of  the  organizations 
demonstrated  the  existence  of  the  four  fundamental  activities  contained  in  the  framework  but  an 
examination  of  the  existing  process  enablers  revealed  various  interpretations  of  required  features.  The 
maturity  matrix  was  used  to  evaluate  each  of  the  organizations  (commercial  and  military)  relative  to  the 
front-end  process  in  the  framework.  The  analysis  revealed  a  significant  gap  between  commercial  and 
military  process  performance.  The  existence  and  application  of  the  process  enablers  was  significantly 
correlated  with  the  organization’s  performance  in  the  four  process  activities  of  the  framework. 

The  implications  of  the  research  indicate  that  military  organizations  need  to  reevaluate  their  current 
practices  in  the  front-end  and  the  application  of  process  enablers  within  their  organizations.  Further, 
military  organizations  should  reexamine  if  the  current  process  structure  for  system  development  in  the 
front-end  need  significant  changes. 
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and  Intelligence  (C3^ 

Budget  Estimate  Submission 
Board  of  Directors 

Command,  Control,  Communications,  Computers,  and  Information 

Cost  as  an  Independent  Variable 

Chairman’s  Guidance 

Commander-in-Chief 

Chairman  of  the  Joint  Chiefs  of  Staff 

Concept  of  Operations 

Chairman’s  Program  Assessment 

Capstone  Requirements  Document  (usually  for  2  or  more  ORDs) 

Chief  of  Staff  of  the  Air  Force 
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DAB 

Defense  Acquisition  Board 

DAE 

Defense  Acquisition  Executive 

DCS 

Deputy  Chief  of  Staff 

DoD 

Department  of  Defense 

DPG 

Defense  Planning  Guidance 

DRB 

Defense  Resources  Board 

FFRDC 

Federally  Funded  R&D  Center 

FOSG 

Flag  Officer  Steering  Group 

FY 

Fiscal  Year 

FYDP 

Future  Years  Defense  Program 

ICT 

Integrated  Concept  Team 

IOC 

Initial  Operational  Capability 

IPL 

Integrated  Priority  Dst 

IPT 

Integrated  Product  Team 

niss 

Integrated  Requirements  Support  System 

J-8 

Joint  Directorate  of  Requirements  and  Planning 

jcs 

Joint  Chiefs  of  Staff 

JRB 

Joint  Review  Board  (pre-JROC) 

JROC 

Joint  Requirements  Oversight  Council 

JRP 

Joint  Review  Panel 

KPP 

Key  Performance  Parameters 

LRP 

Long  Range  Plan 

M&S 

Models  &  Simulations 

MAA 

Mission  Area  Analysis 

MAA 

Mission  Area  Assessment 

MAJCOM 

Major  Command 

MAP 

Mission  Area  Plan 

MAT 

Mission  Area  Team 

MAWG 

Mission  Area  Working  Group 

MDA 

Milestone  Decision  Authority 

MDAP 

Major  Defense  Acquisition  Programs 

MIP 

Modernization  Investment  Plan 

MNA 

Mission  Need  Analysis 

MNS 

Mission  Needs  Statement 

MOE 

Measure  of  Effertiveness 

MOP 

Measure  of  Performance 

MPP 

Modernization  Planning  Process 

MSA 

Mission  Solution  Analysis 

MSP 

Mission  Support  Plans 

MT 

Mission  Task 

NMS 

National  Militaiy  Strategy 

NSC 

National  Security  Strategy 

O-  (number) 

As  in  Officer  Grade  -  (number)  (e.g.  0-6  is  a  Golonel,  0-10  is  a  General) 

OAS 

Office  of  Aerospace  Studies 

ORD 

Operational  Requirements  Document 

OSD 

Office  of  the  Secretary  of  Defense 

OT&E 

Operational  Test  &  Evaluation 
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PB 

President’s  Budget 

PBD 

Program  Budget  Decision 

PDM 

Program  Decision  Memorandum 

PE 

Program  Element 

PEM 

Program  Element  Monitor 

POM 

Program  Objeaive  Memorandum 

PPBS 

Planning,  Programming  and  Budgeting  System 

QFD 

Quality  Function  Deployment  (House  of  Quality) 

R&D 

Research  and  Development 

RAD 

Requirements  and  Acquisition  Division 

RAWG 

Requirements  Action  Woddng  Group 

ROM 

Requirements  Gorrelation  Matrix 

RDT&E 

Research,  Development,  Test  &  Evaluation 

RGS 

Requirements  Generation  Systems 

SAF/AQ 

Secretaiy  of  the  7\ir  Force  for  Acquisition 

SAF/FM 

Secretary  of  the  Air  Force  for  Finances  (e.g.  FMB  for  funding  and  FMC  for 
cost  issues) 

SECAF 

Secretary  of  the  Air  Force 

SECDEF 

Secretary  of  Defense 

SON 

Statement  of  Operational  Need 

SPO 

System  Program  Office 

SPRS 

Space  Planning  and  Requirements  System 

TOA 

Total  Obligation  Authority 

TPIPT 

Technical  Planning  Integrated  Produa  Team 

USD  (A&T) 

Under  Secretary  of  Defense  for  Acquisition  and  Technology  (ASH) 

USSOCOM 

United  States  Special  Operations  Command 
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CHAPTER  1  -  DEVELOPING  THE  NEEDS  AND 
REQUIREMENTS  FOR  WEAPON  SYSTEMS  IN  THE 

US  AIR  FORCE 


Currently,  the  processes  in  place  to  acquire  new  systems  for  the  military  are  very  formal  and  take  a 
long  time  to  navigate.  Current  estimates  of  the  time  required  to  traverse  the  system  are  between  15 
and  20  years  (Stanley  1994);(See  Gansler  1989).  The  time  indicated  is  somewhat  deceiving  as  it 
typically  refers  to  the  ‘start’  of  a  new  acquisition  program.  The  term  ‘start’  usually  refers  to  the  point  in 
time  when  resources  have  been  allocated  to  finish  the  project.  However,  what  about  all  of  the 
activities  that  must  come  before  the  ‘start’? 

The  commercial  world  has  by  practice  refrained  from  entering  into  new  development  projects  without 
understanding  the  ramifications  of  such  an  action.  Most  companies  present  the  pros  and  cons  of  any 
new  venture  in  some  kind  of  fonnal  document  and  use  it  to  base  their  decision.  This  formal 
document  is  known  as  a  ‘business  case’.  It  clearly  states  the  ‘case’  for  the  ‘business’  of  the  new 
venture.  Obviously,  these  business  cases  do  not  appear  magically.  They  take  time  to  develop  and  yet, 
not  too  much  time  that  would  give  a  competitor  the  upper  hand.  They  must  be  done  correaly  too,  as 
some  companies  ‘bet  the  business’  on  new  product  decisions.  In  product  development  “the  front  end 
is  inherently  fuzzy  because  it  is  a  crossroads  where  complex  information  processing,  a  broad  range  of 
tacit  knowledge,  conflicting  organizational  pressures  including  cross-functional  inputs,  considerable 
uncertainty,  and  high  stakes  must  meet"  (Khurana  and  Rosenthal  1998,  pg.72).  For  the  United  States 
Military,  the  front-end  consists  of  the  initial  processes  leading  towards  the  development  of  programs 
and  systems. 

The  description  of  this  pre-activity  in  the  commercial  world  is  known  as  the  “fuzzy-front  end”  of 
product  development.  In  the  militaiy,  three  separate  processes  participate  in  the  “fuzzy  front-end”  of 
the  development  of  a  weapon  system.  These  are  known  as  the  Programming,  Planning,  and  Budgeting 
System  (PPBS),  the  Requirements  Generation  System  (RGS)  and  the  Acquisition  System.  Each  of  the 
services  designates  particular  portions  of  these  processes  by  different  names.  The  degree  of  formality 
and  complexity  among  the  services’  portions  also  vary. 
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(CJCS  1999) 


Figure  1.  Weapon  System  Development  Requires  Intersection  of  Three 

Separate  Systems 


A  three-pronged  effort  is  required  to  begin  a  program;  first,  user  ‘validation  and  approval’  of  the  need 
through  the  RGS,  second,  a  place  in  the  budget  of  the  service  for  the  program  through  the  PPBS,  and 
third,  approval  from  the  proper  Acquisition  authority.  Portions  of  these  systems  are  often  happening 
in  parallel  and  can  be  quite  complicated.  The  PPBS  requires  at  least  two  years  to  get  money 
programmed  and  budgeted  until  resources  are  able  to  be  expended  on  a  project  of  any  kind.  The 
Milestone  Decision  Authority  (MDA)  from  the  Acquisition  System  must  agree  that  both  of  these 
conditions  have  been  met,  and  any  other  levied  upon  the  program,  before  further  product 
development  may  begin  and  a  Milestone  Decision  is  reached. 

The  current  process,  as  explained  above,  for  the  front-end  is  difficult  to  quantify.  However,  assuming 
front-end  processes  are  executed  serially,  and  also  that  the  recommended  process  cycle  times  occur,  a 
relative  cycle  time  for  the  process  can  be  estimated.  For  example,  strategic  planning,  which  can  take 
up  to  a  year,  feeds  both  the  Requirements  System  and  the  PPBS.  To  review  the  notional  cycle  times, 
the  PPBS  requires  2  years,  and  the  Requirements  System  requires  1/2  to  2  years  to  traverse. 
Therefore,  a  'requirement'  in  the  DoD  takes  approximately  2  1/2  to  4  years  to  result  in  a  Milestone  0 
decision.  This  amount  is  an  addition  to  the  commonly  quoted  weapon  system  cycle  time  of  15  to  20 
years.  Add  another  2  1/2  to  3  years  at  least  (because  an  AoA  requires  6  to  18  months  and  the  ORD 
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has  to  traverse  the  RGS  as  well)  until  a  Milestone  I  decision  is  made  and  the  program  is  formally 
started  and  turned  over  to  the  acquisition  community.  These  numbers  equate  to  a  grand  total  of  5  to  7 
years  required  to  make  an  investment  decision  for  the  services  on  a  weapon  system  acquisition. 

Also,  it  appears  that  ‘radical’  or  ‘unprecedented’  leaps  of  technology  and  performance  require  a  much 
longer  amount  of  time  to  emerge  from  the  overall  front-end  system.  For  example,  the  F-22  Concept 
Development,  from  initial  idea  generation  to  program  start,  required  nearly  11  years.  The  first  foray  of 
exploratory  work  began  in  the  early  70s  and  did  not  enter  the  Acquisition  Process  until  November  23, 
1981  (Aronstein,  ITirschberg  et  al.  1998).  Part  of  the  time  delay  can  be  explained  by  the  timing  of  the 
concept  development.  During  the  time  of  the  F-22  Concept  Development,  the  Air  Force  was 
conduaing  several  major  aircraft  purchases,  including  the  F-15  and  the  F-16  aircraft.  Additionally,  the 
B-1  and  B-2  bombers  were  acquired  during  the  1980s  and  the  C-17  during  the  1990s,  diverting  vast 
amounts  of  procurement  dollars  to  these  systems. 

The  Problems 

Despite  the  appearance  that  the  military’s  front  end  is  systematic  in  the  course  of  developing  systems, 
it  exhibits  many  characteristics  that  make  its  processes  appear  ad  hoc.  There  is  no  standardized 
approach  to  the  front-end  of  produa  development  in  the  military,  especially  in  developing  the  concept 
through  actually  developing  the  requirements  for  the  system  (Laubengayer  and  Spearman  1994).  What 
is  wrong  with  ad  hoc  processes?  The  results  can  be  less  than  desirable  or  completely  wrong. 

The  public  has  heard  it  all  before  -  the  legendary  $600  hammers,  the  $1,000  Allen  wrenches,  $5,000 
coffeepots,  wasted  resources,  and  so  on  (Gregory  1989).  The  warfighter  feels  shortchanged  as  well 
and  reacts  poorly  to  these  discoveries.  They  view  all  those  who  participated  in  the  process,  most 
notably  the  defense  contractors  and  acquisition  personnel,  with  a  lack  of  confidence,  distmst  and 
suspicion.  This  atmosphere  does  not  bode  well  for  any  program.  Additionally,  the  current  process  to 
develop  weapon  systems  is  being  blamed  for  several  shortcomings  in  the  military.  One  notable 
shortcoming  is  that  the  current  system  is  unresponsive  to  a  rapidly  changing  threat  environment.  A 
recent  example  of  this  shortcoming  was  highlighted  when  the  process  failed  to  recognize  in  time  (or  at 
all)  the  threat  of  changing  radar  waveform  patterns.  Radar  waveform  patterns  stored  in  aircraft 
defensive  systems  must  be  constantly  updated  to  reflect  the  latest  changes  used  by  anti-aircraft 
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weapomy.  The  lives  of  pilots  patrolling  the  Iraqi  No-Fly  Zone  were  jeopardized  and  it  left  the  US 
militaiy  scrambling  for  a  solution  (Fulghum  1998). 

What  is  wrong  with  a  poorfy^  articulated  requirement?  An  example  of  this  is  when  the  Army  mandated 
using  their  existing  vehicles  and  refused  investing  in  another  type  of  vehicle  for  a  tmck  mounted  anti¬ 
missile  battery.  This  single  requirement  ‘drove  the  solution’  to  a  system  that  could  only  hold  two 
missiles,  although  the  acceptable  range  of  accuracy  required  could  only  be  achieved  with  a  minimum  of 
four  missiles  (DOD  1998).  In  essence,  it  was  a  total  failure  of  the  system  to  produce  and  field  a 
weapon  system  that  met  user  needs.  "The  user  in  the  above  scenario  had  a  legitimate  concern; 
however,  stating  that  simple  and  logical  logistical  requirement  {to  use  existing  vehicles}  drove  the 
process  to  an  expensive  design  solution.  Consideration  of  possible  alternatives  -  remotely  piloted 
vehicles,  airborne  lasers,  satellites,  high  energy  weapons,  kinetic  kill  weapons  -  was  eliminated"  (DOD 
1998,  pg.  51)  almost  from  the  start. 

The  cost  to  realize  requirements  in  a  materiel  solution  has  received  the  most  attention  in  the  formal 
literature.  Consider  this  quote.  “The  United  States  has  clearly  kept  its  military  equipment  at  the 
technological  forefront,  but  the  cost  of  this  has  been  an  increase  of  around  5  -7  percent  per  year  in  the 
unit  cost  of  each  new  generation  of  equipment  (even  alter  adjustment  for  inflation  and  for  the  higher 
unit  prices  associated  with  the  reduced  quantities  typically  purchased  today).  ...  Therefore,  it  is  not 
surprising  that,  as  costs  have  been  rising,  we  have  been  buying  fewer  and  fewer  weapon  systems.  For 
example,  in  1955  the  Department  of  Defense  spent  approximately  $7  billion  (adjusted  to  1982  dollars) 
to  procure  approximately  1,400  military  aircraft.  By  1982  it  was  spending  $14  billion  a  year  for 
approximately  200  aircraft.  This  trend  continues  to  hold  tme  with  the  production  of  the  new  F-22. 
Low-volume  produrtion  runs  further  strain  the  relationships  between  requirements,  acquisition,  and 
the  budget.  Furthermore,  additional  problems  result  from  the  differences  between  the  systems  initial 
estimated  costs  and  the  final  price  tag”  (Gansler  1989,  pg.  7).  Assuming  that  current  development 
costs  of  new  weapon  systems  for  the  US  Air  Force  will  continue  to  increase  at  historical  rates, 
resources  will  soon  be  outstripped  by  demand  unless  something  is  done.  Augustine  observes  that 
given  current  trends,  the  unit  cost  of  one  tactical  aircraft  wiU  currently  outstrip  the  entire  defense 
budget  by  2054  and  the  entire  gross  national  produa  by  the  mid  2100s  (Augustine  1983). 
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According  to  one  study,  the  cost  of  defining  requirements  poorly  is  high.  Given  a  $200  billion  dollar 
acquisition  budget  (in  1987  dollars),  the  direct  cost  of  poorly  defined  user  needs  and  requirements 
ranges  between  $16  to  $24  Billion  dollars  -  8%  to  12%  of  the  budget  (Schlesinger  1987). 

Table  1.  Potential  Cost  Savings  from  Better  Requirements 


Cost  Categoiy 
of  Cost 

Savings 

Budget 

Impacted 

Level 

Impacted 

Ranges  of 

Realistic 

Improvement 

Near 

Mid-Long 

Total 

Requirements, 

Excesses 

$100 

20-40% 

10-15% 

1 

14 

10-15 

Over 

Specification, 

Errors 

$150 

5-15% 

4-6% 

2 

7 

6-9 

Totals 

$200 

24-61% 

12-25% 

$3 

$21 

$16-24 

(Schlesinger  1987). 


Gansler,  whose  unpublished  paper  was  used  to  determine  some  of  the  numbers  in  Table  1,  published 
a  more  detailed  explanation  of  these  numbers.  Those  of  greatest  interest  are  found  in  an  excerpt  from 
his  book.  In  this  example,  Gansler  indicates  that  approximately  $23  BUlion  is  ‘realistic’  from  a  $300 
Billion  Defense  Budget  (i.e.  he  acknowledges  that  there  will  be  no  “perfect”  system  with  no 
inefficiencies)  in  the  amount  of  savings  with  improved  requirements  definition.  This  amounts  to 
about  7.5%  of  the  defense  budget  each  year. 


Table  2.  Problem  Areas  with  Potential  Annual  Savings 


Problem  Area 

Rationale  for  Efficiency 

Potential  annual  savings  from  a 
$300  Billion  Defense  Budget  (in 
billions  of  1989  dollars) 

Designs  primarily  for  maximum 
performance  (with  “gold 

plating”) 

“Design  to  Cost”  and 

producibility  should  save  a  net 
of  10%  of  production  costs 

$15 

Excessive  Specifications 

(product  and  process) 

Over-specification  raises 

acquisition  costs  by  5% 

$8 

Source:  (Gansler  1989,  pgs.  341-342) 


The  potential  savings  in  this  area  are  staggering,  and  these  are  simply  reflections  of  his  ‘realistic’ 
assessment.  This  does  not  imply  what  a  ‘perfea’  system  could  save  overall.  He  does  estimate  that 
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when  pursuing  the  last  5%  of  performance  requirements  in  a  system  the  total  cost  of  the  program  may 
increase  by  as  much  as  30  percent  (Gansler  1989). 

A  recent  survey  of  government  and  contractor  program  managers  (post  Milestone  I)  indicated  that 
problems  caused  by  or  stemming  from  Requirements  cause  program  cost  growth  at  a  rate  of  2.7% 
annually.  Schedule  sHps  of  11.9%  from  program  start  to  IOC  are  not  uncommon  (Rebentisch  1996). 
This  figure  seems  in  line  with  the  percentage  indicated  by  Gansler.  The  somewhat  lower  percentage 
cited  may  be  attributable  to  the  changes  brought  about  by  Acquisition  Reform  in  the  US  Air  Force. 
However,  to  date,  there  have  been  no  changes  to  the  front-end  process  (pre-Milestone  I)  of  the  US  Air 
Force.  This  information  merely  reflects  the  experiences  of  already  existing  programs  (i.e. 
Requirements  Management). 

The  cost  to  execute  the  overall  process  has  rarely,  if  ever,  been  quantified.  However,  a  case  defining 
the  process  cost  for  one  program  run  by  the  US  Air  Force  was  determined  to  be  roughly  5%  of  the 
total  program  costh  The  process  cost  for  development  and  generating  requirements  is  clearly  also 
something  to  consider. 

What  is  the  cause  of  these  problems?  While  simply  speculation,  the  answer  to  this  question  could  be 
that  the  DoD  commits  too  early  to  specific  system  characteristics  and  the  intent  of  the  customer  is 
lost.  Possibly,  the  customer  or  end  user  may  simply  not  be  able  to  communicate  or  articulate  the  need 
or  operational  requirement.  Perhaps  the  developer  or  even  the  customer  turn  their  focus  on  the 
technology  rather  than  on  addressing  the  fundamental  requirements  that  the  system  needs  to  satisfy 
(Laubengayer  and  Spearman  1994).  Here  are  some  additional  explanations  why  the  current  process 
leads  to  results  that  are  less  than  desirable: 

•  There  is  an  inefficient  conversion  of  needs  into  detailed  requirements.  Vaguely  defined 
operational  requirements  are  often  the  result.  Furthermore,  these  operational  requirements  don’t 
flow  efficiently  as  inputs  to  system  requirements  and  the  detailed  technical  requirements  definition 
process  downstream. 


'  The  author  participated  in  developing  a  case  studp  that  examined  the  process  costs  as  part  of  a  class  projea.  The  author  was  part  of  a 
team  that  presented  this  information  as  part  of  its  final  class  projett  (Coaizzo,  Gruszka  et  al.  1999).  This  projea  is  available  upon 
request. 
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•  There  is  a  long  needs-generation  process  with  multiple  steps,  and  it  seems  to  be  accomplished 
using  a  serial  process.  Numerous  organizations  participate  in  the  review  of  Requirements 
documents.  The  hierarchical  nature  of  the  militaiy  means  that  requirements  must  “go  up”  the 
chain  of  command  before  being  seen  by  the  ultimate  decision-makers.  Releasing  a  document  “to 
the  outside”  from  within  an  organization  requires  high-level  sign-off.  (This  is  both  between 
MAJCOMs"  as  well  as  between  the  different  services.)  Revisions  may  require  numerous  iterations 
through  the  chain  of  command. 

•  Because  of  the  currently  long  produa  development  time,  large  steps  in  performance  are  required 
to  justify  the  need  for  a  new  system  vs.  incremental  upgrades.  That  gives  more  opportunity  for 
requirements  changes  as  technology  and  threats  evolve. 

•  The  DoD  joint  planning  process  aas  more  as  a  filter  than  a  coordination  process  (e.g.,  the 
individual  services  are  free  to  start  programs  that  may  duplicate  an  existing  capability  in  another 
service.) 

•  Requirements  are  stated  that  aren’t  absolutely  necessaiy  to  complete  the  mission,  by  either  the 
operational  users  (or  customers),  and/ or  those  that  are  responsible  for  acquiring  these  systems. 
The  reasons  for  this  vaty,  but  probably  range  from  a  lack  of  trust  between  the  different  disciplines 
to  stating  requirements  because  ‘they  had  always  done  so.’ 

•  There  is  a  failure  to  explore  all  possible  alternative  solutions,  as  in  the  previously  mentioned 
example  from  the  Army.  There  is  a  perceived  need  to  ‘hurry  up’  results  for  a  rapid  convergence 
towards  a  single  solution  without  full  analysis.  Existing  solutions  (e.g.,  off  the  shelf,  contractor 
proposed,  etc.)  are  envisioned  as  the  preferred  option  before  consideration  of  actual  mission  needs 
or  possible  alternatives,  which  is  actually  contrary  to  existing  policy.  For  example,  existing  US  Air 
Force  policy  dictates  the  first  and  most  important  step  is  to  understand  the  mission  need  and  then 
search  for  potential  solutions  (USAF  1996;  USAF/DXOR  1999). 


2  A  MAJCOM  is  a  Major  Gammand  in  the  United  States  Air  Force.  There  are  similar  terms  used  for  equivalent  organizations  in  the  other 
US  military  services.  A  commercial  analogy  is  that  of  a  Company  Business  Unit. 
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•  There  are  unrealistic  mission  statements.  There  is  also  a  lack  of  measures  or  analysis  identifying 
relative  cost  effectiveness  of  varying  levels  of  capability.  Mission  requirements  maybe  “cut  and 
pasted”  from  previous  requirements  documents  without  sufficient  review.  Missions  or  threats 
may  be  unrealistic  or  no  longer  exist  in  current  form  in  the  time  required  to  develop  and  field  the 
capability. 

•  Combinations  of  requirements  exist  that  taken  in  concert  are  costly  to  realize.  There  is  a  lack  of 
awareness  or  consideration  of  how  specific  mission  requirements  may  conflict  with  various  other 
elements  of  the  system. 

•  Different  organizations  are  responsible  for  different  aspects  of  the  system,  with  little 
communication  and/ or  budgetary  coordination.  Only  enough  funding  is  provided  (in  some  cases) 
to  complete  analysis  and/ or  development  of  requirements  for  a  single  element  of  a  larger  system 
or  system  of  systems.  A  Joint  program  has  many  “Requirers”  but  only  one  or  a  few  organizations 
are  responsible  for  the  funding  and  execution  of  the  program. 

This  list  does  not  imply  that  the  source  of  all  of  these  shortcomings  are  known  or  easily  solved. 
Rather,  it  builds  a  case  that  the  current  process  is  not  responding  to  the  needs  of  the  warfighter. 

The  military  is  full  of  examples  of  trying  to  deal  with  the  earlier  mentioned  problems  of  the  front-end. 
One  such  method  is  the  Air  Force’s  Rapid  Response  Process  (RRP),  used  recently  during  the  conflict 
in  Kosovo.  The  process  is  “designed  to  streamline  the  acquisition  process  by  reducing  the  layers  of 
bureaucracy,  thereby  delivering  a  capability  more  rapidly.  The  RRP  objective  was  to  submit,  assess, 
approve,  and  fund  a  validated  Combat  Mission  Need  Statement  (C-MNS)  within  24  days  and 
implement  procedures  to  field  the  desired  capability  in  less  than  six  months”  (Smith  1999  pg.  28;  See 
also  USAF/DXOR  1999).  The  drawback  to  this  process  is  that  it  is  only  used  during  conflicts 
(militaiy  action  of  prolonged  duration).  However,  based  on  the  results  of  its  use  during  Desert 
Shield/Desert  Storm  (24  out  of  30  projects  were  approved  and  were  delivered  to  the  field  within  five 
months;  costs  of  acquisition  and  production  were  under  $100  Million),  this  process  seemed  to  work 
well  (Smith  1999).  There  are  other  processes  used  by  the  Air  force  as  well.  One  is  the  Short  Method 
to  Acquire  Ready  or  Replacement  Technologies  (SMART).  This  method  is  for  “mature 
solutions... that  are  fully  funded  and  have  the  potential  to  be  acquired  and  fielded  quickly” 
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(USAF/DXOR  1999).  Reasons  for  using  these  alternative  methods  to  the  existing  process  are  varied, 
but  are  usually  the  result  of  trying  to  shorten  the  typical  acquisition  cycle.  Examples  of  how  to  do  this 
include  the  use  of  Advanced  Concept  Technology  Demonstrators  (ACTDs)\  Advanced  Technology 
Demonstrators  (ATDs),  Commercial  and  Non-Developmental  Items  (CaNDI),  Joint  Warrior 
Interoperability  Demonstrations  (JWID)  Gold  Nuggets,  Kenney  Battlelab  initiatives.  Expeditionary 
Force  Exercise  (EFX)-type  initiatives  and  others  (USAF/DXOR  1999).  But  these  methods,  which  are 
developments  of  the  1990s,  are  responses  to  some  of  the  visible  symptoms  of  the  current  system. 
They  do  not  contribute  to  understanding  the  root  causes  or  solving  them.  Rather,  they  seek  to  shorten 
development  time  by  either  taking  shortcuts  through  existing  processes  or  circumventing  them 
altogether.  The  RRP  and  SMART  processes  only  make  these  shortcuts  and  circumvention  acceptable 
and  permissible. 

Qualitatively,  problems  exists  in  the  way  the  militaiy  -  and  more  specifically,  the  US  Air  Force, 
generates  requirements.  How  can  this  problem  be  really  quantified?  One  way  to  determine  this  is  to 
compare  the  front-end  process  of  the  Air  Force  against  the  other  military  services  and  also  industry. 
What  wiU  distinguish  superior  processes  from  all  others?  For  the  purposes  of  this  study,  a  truly 
systemic  or  ‘holistic’  approach  to  the  front-end  is  hypothesized  to  be  better  than  an  ad-hoc  one.  One 
might  argue  that  the  requirements  system  of  the  US  Air  Force  is  very  methodical,  even  systematic. 
This  is  true.  But  does  the  Air  Force  have  a  system  that  is  really  ‘holistic’  in  its  approach  to  new 
product  development  or  does  it  promote  processes  and  practices  that  contribute  to  the  previously 
listed  shortcomings?  The  USAF  and  the  other  services  will  be  evaluated  to  answer  this  question. 

The  Packard  Commission  made  the  following  assertion  about  the  overall  process:  “The  more  time, 
care,  and  money  invested  at  the  front  end  of  a  project,  the  quicker  and  cheaper  a  better  and  more 
reliable  end  produa  will  get  into  the  hands  of  the  forces”  (Gregory  1989,  Pg.  19).  There  have  been 
many  studies  and  proposals  made  on  how  to  improve  the  current  front-end  process  of  the  militaiy. 
Appendix  G  contains  detailed  information  about  many  of  these  studies  and  proposed  changes  to  the 
front-end  process,  particularly  the  planning  stages.  FFRDCs  or  non-profit  agencies  such  as  RAND 
have  generated  most  of  these  proposals.  Most  of  these  were  also  done  at  the  request  of  the  US  Air 


3  The  reader  is  referred  to  DoD  literature  for  more  backgrottnd  on  these  issues  (USAF/DXOR  1999). 
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Force  and  are  specific  to  the  Air  Force  front-end  process.  Table  7  summarizes  the  information 
contained  in  Appendix  G. 

Table  3.  Proposed  improvements  to  the  current  Air  Force  System 


Concept 

Source  of  information 

Process  affected 

Overview 

Reorganize  OSD 
(A&T) 

Bracken 

All 

Create  Science  & 
Technology  office; 
Concept  Development 
&  Integration  Office; 
and  Acquisition  Office 

Crisis-Action  Planning 

Davis 

PPBS,MPP 

Use  exercises;  stress 
flexibility  and 
adaptiveness 

Assumption  Based 
Planning 

Dewar 

PPBS,MPP 

Thinking  about 
uncertainty  and 
organizational  issues 

Constraining  the  MPP 

Farr 

MPP,  PPBS 

Use  an  IP  model  to 
determine  correct  mix 
of  resources  for 
systems 

Modernization 
Investment  Plan 

ORiorden 

MPP,  PPBS 

It  is  a  goal- 

programming  tool  that 
links  strategy  with 
available  resources. 

Concept  Development 
Framework 

Lewis 

MPP,  Requirements 
Generation  System 

Supports  the  formation 
of  Concept  Operations 
Groups  to  refine 
conceptual  ideas 

Operational 

Acquisition 

Smith 

Requirements  Process, 
Acquisition  System 

Further  integration  of 
operational  warfighter 
(CINCs)  into 
development  and 
acquisition  of  systems 

None  of  these  studies  or  reports  has  looked  at  the  overall  product  development  system  of  the  military. 


This  work  will  examine  the  entire  system  from  a  holistic  viewpoint  in  order  to  provide  additional 
recommendations,  based  on  sound  reasoning  and  supporting  evidence,  on  ways  to  eliminate  the 
current  problems  in  today’s  process. 


Scope  of  the  investigation 


The  Air  Force  and  the  DoD  typically  deal  with  produas  that  are  technologically  advanced,  very  capital 
intensive,  and  very  complex,  both  from  an  architectural  and  platform  perspective.  Other  industries 
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with  similar  circumstances  include  commercial  aerospace  and  commercial  airliners.  Additional 
industries  worth  examining  are  those  with  rapidly  evolving  technology  and  highly  complex 
development  and  manufacturing  processes. 

The  goal  of  this  research  is  to  be  explanative  in  nature  and  to  answer  real  world  questions.  The  leading 
theories  in  this  area  have  not  looked  primarily  at  highly  complex,  technologically  advanced,  capital- 
intensive  products.  This  study  seeks  to  extend  the  application  of  these  theories  into  this  area  and 
identify  the  best  practices  in  use.  This  effort  will  look  at  the  fuz2y-front  end  in  view  of  these 
conditions  in  these  industries  and  also  compare  them.  The  desire  of  this  research  is  to  be  both  broad 
and  deep  across  the  spectrum  of  applicability. 

‘Best  practices’  among  the  different  industries  will  be  highlighted  and  clarified.  Potential  applications 
will  be  demonstrated  through  the  products  contained  in  this  work,  as  they  apply  to  both  commercial 
and  military  settings.  This  research  will  also  serve  to  benchmark  the  existing  practices  of  these 
industries  and  also  document  any  trends  that  exist  versus  what  existing  theory  prognosticates.  Finally, 
a  tool  win  be  developed  to  enable  any  organization,  commercial  or  military,  to  determine  visually 
where  they  are  compared  to  other  organizations  and  best  praaice. 

The  ultimate  objective  of  this  research  will  be  to  develop  policy  recommendations  that  encourage 
implementation  of  best  praaices  into  the  “fuzzy  front-end”  of  weapon  system  produa  development 
for  the  US  Air  Force.  The  following  dialogue  in  this  work  will  demonstrate  the  potential  for 
improvement  in  the  fuzzy  front-end  of  weapon  system  development  in  the  US  Air  Force.  Indeed, 
there  is  much  to  be  gained  by  looking  at  the  military  at  large  and  doing  so  in  comparison  with  the  best 
the  commercial  world  has  to  offer. 

Hypothesis/Assertion 

The  core  assertion  of  this  research  is  that  a  systematic,  holistic  Requirements  Process  is  better  than  an 
ad  hoc  one.  “Flying  by  the  seat  of  your  pants”  may  work  some  of  the  time,  but  a  planned  process  will 
consistently  produce  better  solutions.  Furthermore,  the  main  hypothesis  of  this  work  is  that  without 
the  proper  application  of  organizational  and  business  enablers,  product  development  will  not  be  as 
successful  (as  measured  by  outcome  metrics)  despite  the  existence  of  ‘Best  Practices’  applied 
throughout  the  process. 
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As  the  framework  asserts  that  Organizational  and  Business  Enablers  are  required  for  an  advanced 
front-end,  and  that  an  advanced  front-end  demonstrates  characteristics  that  are  desirable;  it  is 
hypothesized  that  the  enablers  will  be  positively  correlated  with  each  stage  of  the  framework  as  well  as 
with  the  overall  process. 

Key  Questions 

There  are  several  questions  that  will  be  investigated  during  this  research.  Key  questions  being 
addressed  by  this  research  are: 

1.  What  are  the  metrics  and  the  current  effectiveness  of  the  Requirements  Process  in  the  US  Air 
Force.^ 

2.  How  does  the  AF  process  compare  with  other  services?  The  commercial  world?  How  do  the 
processes  compare  with  the  results  found  in  the  literature? 

3.  What  are  the  key  elements  of  a  process  that  uses  Best  Praaices?  How  might  identified  Best 
Practices  be  applied  to  the  US  Air  Force  process?  What  is  required  to  implement  these  Best 
Practices?  Are  there  things  inherent  in  the  system  that  prevents  widespread  application  of  Best 
Practices? 

Primary  Deliverables 

There  are  three  primaiy  products  of  this  research. 

1.  A  Front-end  Framework  (developed  and  presented  in  Chapter  Three)  categorizes  and  facilitates 
understanding  of  the  current  needs/ requirements  generation  process  in  the  Air  Force,  the  other 
services,  and  representative  commercial  firms. 

2.  A  Process  Maturity  Matrix  forms  the  basic  set  of  Best  Practices  for  the  Fuzzy  Front  End,  derived 
from  the  framework  and  the  other  data  sources. 

3 .  Implications  of  and  recommendations  for  policy  changes  in  the  US  Air  Force. 
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what  this  effort  will  not  do 


This  effort  will  not  look  specifically  at  the  Planning,  Programming,  Budgeting  System,  the 
Requirements  Generation  System,  or  the  Acquisition  System.  However,  the  interseaion/interfaces  of 
these  three  and  other  processes  will  be  discussed  and  evaluated  as  part  of  this  research.  Any 
evaluation  of  the  military's  front  end  will  be  done  from  an  integrative  viewpoint,  or  holistic  viewpoint, 
rather  than  parsing  functions  or  artivities  into  separate  systems.  There  is  currently  other  research 
underway  by  the  Institute  of  National  Security  Studies,  the  Pentagon"'  and  the  General  Accounting 
Office  evaluating  the  strengths  and  weaknesses  of  these  systems  separately.  Opportunities  for  synergy 
with  the  above  named  efforts  will  be  aggressively  pursued. 

Furthermore,  Requirements  management  -  an  activity  defined  to  occur  after  the  initial  set  of 
requirements  has  been  determined  -  will  not  be  examined.  This  is  beyond  the  scope  of  this  effort. 

Summary 

In  general,  the  issues  dealing  with  the  front-end  of  produa  development  are  being  fiscally  constrained, 
having  effective  measurement,  avoiding  stovepiping  activities,  maintaining  the  correct  focus,  strategy, 
and  accountability,  all  while  doing  it  in  a  timely  manner.  These  issues  are  important  to  the  US  Air 
Force,  the  entire  DoD  and  to  the  entire  US  Government.  Indeed,  these  issues  can  be  extended  to 
commercial  companies  because  they  have  widespread  application. 

The  current  process  used  by  the  US  Military  to  take  user  needs  and  requirements  and  develop  them 
into  a  set  of  coherent  ideas,  (along  with  maturing  the  idea  and  establishing  the  organizational 
momentum  to  get  a  project  started),  is  complicated  at  best  and  very  difficult  to  navigate.  Furthermore, 
adding  the  actions  of  strategy  and  planning,  along  with  the  budgeting  process  for  obtaining  the 
necessary  funds  to  develop  these  requirements  into  a  fielded  capability,  although  not  necessarily  timely, 
to  a  holistic  view  of  requirements  generation  turn  that  view  into  one  of  disappointment  and  extreme 
concern.  The  system  probably  functions  only  as  well  as  it  does  thanks  to  the  dedication  and  sacrifice 
of  those  people  working  within  the  system. 


■*  A  Section  912  Requirements  study  looking  at  the  Requirements  Process  and  its  interface  with  the  otlrer  processes. 
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The  key  issues  to  be  addressed  in  this  work  are  those  revolving  around  the  'process'  of  the  fuzzy  front- 
end.  These  include  measures  such  as  cycle  time,  enablers  such  as  common  communication  platforms, 
and  interfaces  between  the  various  parallel  processes  that  need  to  be  coordinated  (or  overall  system 
process  design).  How  does  the  current  system  (in  the  US  Military  generally  and  the  US  Air  Force 
specifically)  really  work?  Where  are  its  strengths  and  weaknesses?  What  can  be  learned  by  looking  at 
various  industries  and  the  processes  they  use  at  the  front-end  of  their  product  development  processes? 
Answering  these  questions  will  likely  reveal  a  set  of  best  practices  for  user  needs/requirements 
generation. 

This  work  aims  to  provide  the  decision-maker  with  an  idealized  front-end  process  and  accompanying 
measures  so  that  existing  processes  and  procedures  may  be  evaluated.  Furthermore,  a  maturity  matrix 
will  be  presented  to  show  process  maturity  and  room  for  improvement  along  with  implementation 
suggestions  to  move  toward  best  practices  in  user  needs  and  requirements  generation  within  the 
'fuzzy-front-end'  of  product  development. 
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CHAPTER  2  -  SETTING  THE  STAGE  FOR 
UNDERSTANDING  THE  PROBLEMS 


This  chapter  will  examine  some  of  the  latest  thinking  about  the  ‘fuzzy  front-end’  of  New  Product 
Development  in  commercial  industry.  Its  strengths  and  weaknesses  will  be  discussed.  Next,  the 
military  process  will  be  discussed  relative  to  the  existing  literature.  Finally,  the  drawbacks  in  the 
literature  will  be  discussed.  This  sets  the  stage  for  the  development  of  the  research. 

Lean  Thinking  and  Lean  Principles  for  the  front-end 

During  the  early  1980s,  the  U.S.  Industry,  and  the  U.S.  Automobile  Industry  in  particular,  was 
suffering  from  a  flood  of  foreign  goods  to  the  consumer  market  that  were  of  higher  quality  and  sold  at 
much  lower  prices.  The  U.S.  Defense  Industry  mirrored  those  problems  of  high-cost  although  quality 
was  stiU  good  enough  on  US  Military  products  for  them  to  be  sold  to  our  allies  and  other  nations. 
However,  the  U.S.  Defense  Industry  had  one  advantage  over  their  other  industrial  counterparts  -  the 
Defense  Industry’s  customer,  the  U.S.,  was  forced  to  buy  from  them  the  systems  that  were  produced 
(Gansler  1989). 

The  crisis  in  industry  kicked  off  an  effort  at  MIT  that  later  resulted  in  the  publishing  of  "The  Machine 
That  Changed  the  World."  It  specifically  addressed  the  challenges  the  American  automotive  industry 
faced  along  with  addressing  how  another  country's  industry  was  doing  so  well.  Out  of  this 
understanding  grew  the  concept,  principles,  and  paradigm  of  "Lean".  Thinking  in  a  lean  fashion 
requires  one  to  address  five  specific  areas:  value  defined  in  terms  of  the  product;  the  ‘value  stream’  for 
each  product;  allowing  value  to  ‘flow’  without  interruptions;  forcing  the  customer  to  ‘pull’  value  from 
the  system;  and  pursuing  perfection  (Womack  and  Jones  1996).  Furthermore,  value  is  directly 
opposed  to  ‘muda’,  Japanese  for  waste.  Muda  is  any  activity  that  absorbs  resources  but  adds  no  value 
or  creates  no  value  (Womack  and  Jones  1996).  The  challenge  remains  to  be  seen  if  the  American 
aerospace  industry,  particularly  those  involved  in  defense,  can  apply  the  principles  of  lean. 

The  Lean  Aerospace  Initiative  has  done  much  to  develop  the  knowledge  and  diffuse  it  through  the 
aerospace  industry  in  the  1990s.  In  this  regard,  product  development  has  become  an  area  where  little 
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information  has  existed  relative  to  the  principles  of  "lean".  Part  of  the  reasons  for  this  is  that  muda 
has  always  been  defined  in  terms  of  manufacturing  or  physical  operations.  Muda  has  several  known 
forms:  “defects  (in  products),  overproduction  of  goods  not  needed,  inventories  of  goods  awaiting 
further  processing  or  consumption,  unnecessary  processing,  unnecessary  movement  (of  people), 
unnecessaiy  transport  (of  goods),  and  waiting  (by  employees  for  process  equipment  to  finish  its  work 
or  on  an  upstream  activity)”  (Womack  and  Jones  1996,  pg.  313).  Womack  and  Jones  added  “the 
design  of  goods  and  services  which  do  not  meet  users’  needs”  (Womack  and  Jones  1996,  pg.  313). 
These  forms  of  waste  have  equally  analogous  forms  within  product  development  (Womack  and  Jones 
1996). 

Most  commercial  industries  have  become  revitalized  over  the  past  decade  as  Lean  Principles  and  Lean 
Thinking  have  become  an  important  part  of  everyday  business  and  muda  has  been  aggressively 
reduced  and/ or  eliminated.  The  US  is  enjoying  an  era  of  unprecedented  economic  expansion  and 
growth,  yet  the  defense  aerospace  industry  continues  to  struggle.  Why  is  this  so? 

Part  of  the  answer  is  that  the  defense  department  has  remained  relatively  unchanged  throughout  the 
past  quarter  century,  although  calls  for  change  and  reform  have  become  even  more  audible. 
Acquisition  Reform  in  the  US  Air  Force  began  in  earnest  in  the  midT990s.  Drastic  changes  have 
since  taken  place  and  many  improvements  have  resulted.  However,  the  process  by  which  the  defense 
department  generates  requirements  and  plans  for  them,  including  resource  allocation,  have  not 
changed  at  all.  Therefore,  the  resulting  tensions  between  systems  undergoing  tremendous  changes  and 
those  that  have  not  are  reaching  a  clamorous  level.  Furthermore,  until  the  rruktaiy  changes  the  way  it 
goes  about  its  product  development  business,  the  defense  aerospace  industry  has  little  incentive  to 
change  and  embrace  the  thinking  and  principles  that  have  turned  the  rest  of  American  industiy 
around. 

Commercial  Industry  has  spent  a  lot  of  time  and  effort  in  focusing  and  improving  their  product 
development  front-end  in  addition  to  just  improving  manufacturing  processes  and  capability.  A  closer 
look  at  their  experience  in  this  area  is  warranted. 
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The  Fuzzy  front-end  in  the  commercial  world 

This  stage  of  new  product  development  is  a  huge  area  of  interest.  The  reasons  for  this  interest  are 
quite  compelling  in  that  the  research  has  revealed  information  in  what  had  been  largely  ‘fuzzy’  - 
information  about  practices,  methods,  and  processes  that  has  yielded  success  in  new  product 
development. 

What  is  the  importance  of  this  information?  Done  well,  the  early  phases  of  product  development  are 
associated  with  shorter  development  cycles,  which  facihtate  the  incorporation  of  newer  technologies 
and  improvements  to  products  in  produaion  (Bacon,  Beckman  et  al.  1994).  Also,  “recent  research  on 
produa  design  and  development  processes  suggests  that  the  management  and  organization  of  the 
early  stages  of  the  process  affect  product  success  or  failure  in  the  marketplace”  (Bacon,  Beckman  et  al. 
1994,pg.32). 

Khurana  and  Rosenthal  looked  at  an  Integrated  approach  to  product  development.  Two  important 
themes  emerged  from  their  research:  the  power  that  comes  from  a  ‘holistic’  front  end,  and  the 
importance  of  the  organizational  and  business  context  in  creating  an  effeaive  front-end  process 
(Khurana  and  Rosenthal  1998).  An  important  prerequisite  for  creating  a  holistic  front  end  is 
establishing  links  between  business  strategy,  product  strategy,  and  key  decisions  in  the  front  end 
(Khurana  and  Rosenthal  1998). 

“The  early  stages  of  new  produa  development  cycles  are  charaaerized  by  relatively  low  rates  of 
expenditure  and,  accordingly,  changes  in  produa  features  or  target  markets  incur  lower  cost  penalties. 
Moreover,  these  early-stage  decisions  have  significant  implications  for  the  costly  “downstream” 
investments  in  the  development,  manufacturing,  and  marketing  aaivities  associated  with  a  new 
produa”  (Bacon,  Beckman  et  al.  1994,  pg.  32).  Research  by  Cooper  and  Kleinschmidt  indicate  from 
their  study  of  125  new  produa  development  projeas  in  8  different  industries,  successful  projeas 
spent  twice  the  amount  of  money  and  almost  twice  the  amount  of  man-days  in  the  front  end  than  did 
projeas  that  failed  (Cooper  and  Kleinschmidt  1988). 

The  fundamental  purpose  of  these  early  stages,  with  their  limited  resources,  is  to  gather  the  right  kind 
of  information  in  a  way  that  allows  the  translation  of  user  needs  into  requirements.  Research  by 
Cause  and  Weinberg  indicate  that  a  requirement  changed  in  the  design  phase  is  3  to  6  times  more 
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expensive  than  changes  in  the  initial  requirements  phase.  Changing  requirements  during  acceptance 
testing  increases  the  cost  of  changing  the  requirement  by  30  to  70  times  verses  changing  it  during  the 
initial  requirements  phase  (Cooper,  Wooten  et  al.  1998). 

Robert  G.  Cooper  is  probably  the  most  notable  researcher  in  this  area.  His  work  has  been  cited 
hundreds  of  times  by  other  researchers  in  the  field  of  new  product  development,  especially  that 
relating  to  the  ‘fuzzy’  front  end.  Some  of  his  more  recent  research  echoes  many  of  the  same  things 
written  above.  Cooper  found  that  “having  a  high  quaKty  new  product  process  had  the  strongest 
impact  on  business’s  new  product  performance”  (Cooper  1996,  pg.  465).  A  high  quality  process, 
according  to  Cooper,  is  one  that  contains:  solid  up-front  homework;  Sharp,  early  product  definition; 
Strong  market  orientation  (voice  of  the  customer);  Tough  go/kill  decision  points;  Quality  of  execution 
throughout;  a  complete,  thorough  New  Product  process;  and  a  flexible  process  (Cooper  1996). 

In  his  study  of  203  industrial  products,  soHd-up  front  homework  (market  and  technical  assessments), 
gave  a  new  product  a  43.2%  better  chance  of  success  (Cooper  1996).  From  103  Chemical  products 
studied,  those  done  with  good  homework  had  2.4  times  the  success  rate  and  2.2  times  the  market 
share  verses  those  done  poorly  (Cooper  1996).  Similarly,  “sharp,  early  produa  definition  enhanced 
project  success  rates  by  59.2  percentage  points;  such  well-defined  projects  had  3.7  times  the  success 
rate  and  1.6  times  the  market  share  as  those  which  lacked  definition;  and  product  definition  was 
significantly  and  strongly  correlated  with  performance”  (Cooper  1996,  pg.  470).  Finally,  the  customer 
or  user  plays  an  extremely  strong  role  in  successful  new  product  development;  75%  of  all  successful 
ideas  come  from  them  (Cooper  1996).  According  to  the  earlier  SAPPHCT  studies,  “an  understanding 
of  user’s  needs  was  the  most  important  discriminator  between  product  success  and  failure  ...  and 
separated  successes  from  failures  in  83%  of  the  cases”  (Cooper  1988). 

Khurana  observed,  “The  primary  front-end  deliverables  should  be  the  product  concept  (clear  and 
aligned  with  customers  needs),  the  product  definition  (explicit  and  stable),  and  the  project  plan 
(priorities,  resource  plans,  and  project  schedules)”  (Khurana  and  Rosenthal  1997,  pg.  106). 

Rosenthal  and  Khurana  propose  several  ways  to  enhance  the  effectiveness  of  product  development 
efforts.  They  underscore  the  need  for  a  project  leader,  a  core  development  team,  and  an  executive 


5  A  study  conducted  by  Sussex  University,  England  (Rothwell  1985). 
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review  committee,  and  emphasize  that  their  roles  must  be  complementaiy  (Khurana  and  Rosenthal 
1997).  Once  the  roles  for  these  people  are  explicitly  defined,  they  suggest  the  following  heuristics  will 
make  the  front  end  less  “fuzzy”: 

•  “The  core  team  resolves  produa  definition  and  project  planning  issues  or  refers  them  to  an 
executive  committee. 

•  Responsibility  for  ensuring  that  produa  definition  and  concept  testing  are  balanced  between 
thoroughness  and  speed.  This  responsibility  is  given  to  one  of  the  roles. 

•  One  of  the  roles  will  ensure  that  resources  are  allocated  to  a  projea,  as  specified  in  the  projea 
plan. 

•  One  of  the  roles  will  identify  emerging  technologies  for  inclusion  in  future  produa  platforms. 

•  One  of  the  roles  will  have  the  authority  to  ensure  that  produas  developed  by  several  business 
units  or  a  unit  and  one  or  more  “partners”  are  aligned  along  produa/ component  interfaces, 
development  schedules,  market  focus,  and  technology  commitments”  (Khurana  and  Rosenthal 
1997). 

Additionally,  they  found  prior  to  a  funding  decision,  a  team  must  make  six  key  decisions.  1.  Identify 
customer  needs,  market  segments,  and  competitive  situations.  2.  Perform  a  technology  evaluation  of 
current  capabilities  and  requirements,  as  well  as  the  alignment  with  existing  business  and  technology 
plans.  3.  Identify  core  produa  requirements.  4.  Test  the  concept.  5.  Specify  the  resources  needed  to 
complete  the  projea.  6.  Identify  key  risks  and  challenges  (Khurana  and  Rosenthal  1998).  These  are  all 
typical  ingredients  of  a  business  case  prepared  for  a  management  decision. 

The  most  fuzzy  and  least  explicit  of  all  pre-phase  zero  (pre-business  case  decision)  aaivities  are  the 
visions  about  the  business,  the  projea,  and  the  produa  (Khurana  and  Rosenthal  1998).  These  ideas 
must  be  clearly  articulated  for  projea  success.  The  development  of  a  business  case  for  a  new  produa 
helps  in  this  articulation. 

Murphy  and  Kidmar  reiterate  the  need  for  a  solid  business  case  because  It  can  be  critical  in  evaluating  a 
proposed  projea  (Murphy  and  Kumar  1996).  Additionally,  they  recommend  a  thorough  evaluation 
and  study  of  a  proposed  projea  prior  to  any  development.  This  study  should  be  a  key  component  in 
the  business  plan.  Also,  “a  feasibility  stucfy  that  assesses  a  projea  in  terms  of  its  compatibility  with 
organizational  strengths  was  found  to  be  crucial  for  developing  new  produas  on  time  and  within 
budget”  (Murphy  and  Kumar  1996,  pg.  439). 
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Natural  barriers  to  achieving  a  holistic  front  end  occur  when  communication  requirements  and 
coordination  in  the  new  product  development  process  is  not  met.  Why?  First,  “the  sources  of 
expertise  are  spread  across  organizational  boundaries.  This  makes  the  problem  ‘sticky’^  because  the 
required  information,  expertise,  and  authority  are  likely  to  be  located  in  different  individuals  or  roles. 
The  front  end  requires  extensive  information  gathering  and  analysis  to  facilitate  the  development, 
testing,  and  refinements  of  the  new  product  concept,  but  this  information  is  not  available  in  one  place, 
role,  or  function.  Second,  key  decisions  to  be  made  on  technology,  cost,  schedule,  risk,  and 
organizational  resources  are  highly  interrelated.  Lacking  a  holistic  process,  the  authority  for  making 
these  decisions  is  dispersed  throughout  the  organization.  Thus,  these  cross-functional  decisions 
require  an  extraordinary  degree  of  coordination  among  senior  management,  project  managers, 
functional  managers,  and  core  team  members.  These  linkages  are  difficult  to  achieve  for  normal 
design  and  development  activities,  but  are  even  more  so  for  the  front  end.  Finally,  since  these  sets  of 
assessments  transcend  any  single  new  produa  concept,  the  coordination  requirements  in  the  front  end 
become  very  subtle.  These  include  routine  linkages  among  the  already  complex  activities  of  strategy 
formulation,  technology  mapping,  market  analysis,  portfolio  analysis,  and  resource  planning”  (Khurana 
and  Rosenthal  1998,  pg.  67). 

Khurana  and  Rosenthal  propose  three  k^  components  are  required  to  enable  achievement  of  the 
linkages  discussed  above.  Additionally,  these  will  bring  more  order  and  predictability  to  the  front  end: 
1)  A  process  orientation;  2)  Explicitness  of  the  product  definition;  and  3)  A  broader  set  of  business 
considerations  while  making  project  justification  decisions  (e.g.,  understanding  the  business  unit’s 
product  portfolio,  and  including  supply  chain  considerations  during  product  definition)  (Khurana  and 
Rosenthal  1998).^ 

Finally,  Rosenthal  and  Khurana  put  together  a  table  of  the  common  success  factors  in  the  front-end  of 
product  development  based  upon  earlier  research  and  a  literature  review.  There  are  four  main  areas  of 
focus  they  identified. 


^  Idea  first  expotmded  upon  by  von  Hippel  (vonHippd  1988). 

7  For  more  information,  please  see  table  entided  “Where  best  practice  is  headed”  in  this  article  (Khurana  and  Rosenthal  1998). 
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Table  4.  Common  Success  Factors  in  the  Front-end  of  Product  Development 


Product  Strategy 

Product  Definition 

Project  Definition 

Organizational  Roles 

Product  Strategy 
formulation  and 
articulation 

Product  Portfolio 
planning 

Product  Concept 

Clarity 

Customer  Needs 

Product  Definition 

Value  Chain 
Considerations  in 
Product  Definition 

Front-end  Project 
Definition  and 

Planning 

Resource  Planning 

Organizational 

Structure  (teams, 
project  manager) 

Leadership  by 

Executive  Reviews 

(Khurana  and  Rosenthal  1998)® 


Other  ways  to  frame  the  front-end  of  product  development 

Numerous  other  authors  have  indicated  ways  to  approach  the  issues  surrounding  the  front-end  of 
product  development.  Each  of  these  is  different  in  terms  of  the  areas  of  focus  as  well  as  their 
applicability  to  the  overall  front-end  of  produa  development  (some  are  very  specialized  and  deal  with 
specific  occurrences).  The  various  ways  include  techniques  (such  as  the  Missed  Elevator  Approach), 
measures  (such  as  cycle-time  measurements),  theories  (such  as  the  theoretical  framework  of 
requirements  generation),  and  analogies  (such  as  the  information  assembly  line).  Appendix  A 
describes  in  detail  the  frameworks  that  are  presented  in  this  table.  The  information  presented  in  the 
appendix  and  table  is  not  all-inclusive.  There  are  virtually  innumerable  ways  to  address  these  issues. 
The  appendix  and  table  only  give  a  sampling  of  the  different  kinds  of  methods  available  to  frame  the 
front-end  of  product  development.  The  table  highlights  the  key  features  as  well  as  some  of  the 
perceived  drawbacks  of  each  framework  by  this  author. 


Table  5.  Specific  Frameworks  to  understand  the  Front-end 


Suggested  Practice 

Proposed  by 

Key  Features 

Drawbacks 

Front-end  Process 
Capability  Mapping 

Khurana  and  Rosenthal 
(Khurana  and 

Rosenthal  1998) 

Classification  scheme 
provides  a  measure  of 
process  maturity  and 
can  identify  areas  for 
improvement. 

Method  does  not 
indicate  what 
constitutes  an  ‘area  for 
improvement’;  also 
relies  upon  detailed 
understanding  of 

*  A  table  of  common  problems  associated  with  a  poor  job  done  at  the  front  end  of  produa  development  is  contained  in  (Khttrana  and 
Rosenthal  1998). 
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existing  process  for 
application. 

Missed  Elevator 

Khurana  and  Rosenthal 
(Khurana  and 

Rosenthal  1998) 

Freeze  Requirements 
Early,  put  into  next 
release 

Relies  upon  short 
produa  cycles  to  be 
effective 

Nyquist  Theorem  / 
Clockspeed 

Patterson  (Patterson 
1993),  Fine  (Fine  1999) 

Sample  environment 
for  requirements  twice 
as  often  as 

process/ system  cycle 
time 

Assumes  cycle  time  is 
known  and  measurable. 

Information  Assembly 
Line 

Patterson  (Patterson 
1993) 

Applies  techniques  for 
assembly  line 
management, 
operations 
management  to 
knowledge 

Assumes  process  in 
place  supports  these 
techniques.  System 
must  be  correctly 
modeled  in  order  for 
principles  to  be  applied. 

Organizational 

Competencies 

Rosenthal  (Rosenthal 
1998) 

Advocates 
organizational 
structures  and 
approaches  to 
development  of  new 
produas 

Most  familiar  to  users. 
Requires  dedication  to 
principles  and 
understanding  of 
proper  application. 

Cycle  Time  in  the 

Front  -  End 

Patterson  (Patterson 
1993) 

Statement  of  link 
between  elapsed  time 
and  time  to  product 
launch  decision 

Metric  is  very  difficult 
to  measure  as  starting 
point  is  veiy  ambiguous 

Stages  for  Searching  for 
User  Needs  / 
Requirements 

Conway,  McGuinness 
(Conway  and 
McGuinness  1986) 

Describes  activities  in 
development  of 
requirements  in 
organizational  terms 

Difficult  to  determine 
when  one  stage  ends 
and  the  other  begins. 

Theoretical  Framework 
to  generate 

Requirements  from 
Information 

Cooper,  Wootton 
(Cooper,  Wooten  et  al. 
1998) 

Provides  holistic 
framework  of 
requirements 
development  from 
organizational  and 
individual  perspectives. 

It  is  difficult  to  identify 
internal  and  external 
sources  of  influence.  It 
is  also  difficult  to 
ensure  that  others  are 
in  complete 
understanding  / 
agreement  throughout 
the  process. 

Techniques  to  gather  and  evaluate  user  needs  and  requirements 

In  addition  to  using  the  frameworks  above  to  understand  the  front-end  process,  several  techniques 
exist  that  act  to  enable  the  front-end.  Using  one  of  these  techniques  is  necessary  for  the  proper 
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functioning  of  a  product  development  front-end.  These  techniques  are  methods  or  ways  to  elucidate 
(such  as  using  the  QFD  Process),  gather  (such  as  using  Interviews  and  Surveys),  and  evaluate  (such  as 
the  Pugh  Method)  user  needs  and/ or  requirements  for  the  front-end.  The  process  of  the  front-end 
deals  with  how  these  techniques  are  incorporated  into  the  overall  process  that  occurs.  Appendix  B 
contains  a  more  lengthy  discussion  about  some  of  the  different  techniques.  The  appendix  is  not  all- 
inclusive;  it  serves  to  indicate  the  variety  of  methods  available  for  the  practioner  to  use. 

When  is  each  technique  effective?  According  to  Dahan,  for  an  incremental  product,  surveys  and  focus 
groups  could  be  used  to  identify  the  key  needs,  a  conjoint  analysis  to  prioritize  the  needs,  and  use 
QFD  for  concept  seleaion.  However,  for  a  more  revolutionary  product,  “leading  edge  users  and 
repertory  grids  might  help  identify  key  needs,  generate  multiple  prototypes,  and  conduct  pre-market 
tests  to  observe  actual  customer  usage”  (Dahan  1998,  pg.  2). 


New 

Users 


Experience 

With 

Users 


Existing] 
Users 


When  is  Each  Technique  Effective? 


Cultural 

Anthropology 


Repertory 

Grids 


/ 

r 

Interviews 

r  ^ 

Surveys 

J 

_ ^ 

Perceptual 

Maps 


Focus 

Groups 


Lead  Users 


Empathic  Design 


Incremental  " 
Improvement 


Project  Scope 


Revolutionary 

Breakthrough 


(Dahan  1998) 

Figure  2.  Notional  Scope  of  Technique  Effectivity 
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However,  one  of  the  dangers  of  listening  too  closely  to  customers  comes  from  the  example  of  the 
computer  disk  drive  industry.  Christensen  of  the  Inmiator’s  Dilemma  has  pointed  out  how  previous 
industry  players  were  Hstening  to  their  customers  so  well  that  they  failed  to  comprehend  the  new 
markets  of  customers  emerging  with  new  applications  for  computer  disk  drives  (Christensen  1997). 
This  is  an  example  of  'disruptive  technologies'  that  can  change  the  dynamics  of  a  given  market  (Bower 
and  Christensen  1994).  Ultimately,  these  industry  players  were  shut  out  of  the  new  markets.  This 
highlights  the  delicate  balance  that  must  exist  between  listening  to  the  user  and  interpreting  what  the 
user’s  true  needs  are. 


Leonard-Barton,  Wilson,  and  Doyle  indicate  three  items  developers  must  consider  so  that  users’ 
suggestions  do  not  limit  product  designs.  “First,  they  see  the  potential  to  apply  technology  within  their 
own  bounded  context  and  will  naturally  influence  the  design  of  the  new  product  or  process  to  meet 
needs  within  that  particular  environment.  ...  Second,  users  are  not  all  equally  proximate  to  the  latest 
trends  in  usage  patterns. . . .  Finally,  and  most  difficult,  users  cannot  see  their  world  through  the  eyes  of 
the  technologist  and  therefore  cannot  know  what  solutions,  functions,  enhanced  features,  or 
capabilities  a  technology  may  offer”  (Leonard-Barton,  Wilson  et  al.  1994,  pg.  8). 


Therefore,  it  is  not  only  necessary  to  sometimes  ignore  what  users  say  they  want,  but  to  also 
sometimes  ignore  the  feedback  they  give  as  well.  If  initial  feedback  from  users  were  heeded, 
consumers  today  would  not  have  the  VCR,  fax  machines,  24  hour  news  channels,  minivans,  and 
numerous  other  'innovative'  produas  that  have  taken  the  markets  by  storm  (Martin  1995). 

Table  6.  Techniques  to  gather  user  needs  and  requirements 


Technique  for 
Requirements 
Generation 

Identified  or 
reported  by 

Main  idea 

Advantages 

Disadvantages 

Sources  of  Ideas 

Conway  (Conway 
and  McGuinness 
1986) 

Six  chief  sources 
of  ideas  or 
descriptors 
surrounding  the 
method 

Helps  identify 
which  types  of 
sources  the 
industry  finds 
most  productive 

Can  lead  to 
confusion  to 
those  who  do  not 
understand  use  of 
terminology. 

Subject  Matter 
Experts 

Dahan  (Dahan 
1998) 

Persons  with 
experience  in  the 
area  are  able  to 
articulate  end  user 
needs 

Bring  vast 
experience  to 
knowledge  area; 
have  intuitive  feel 
for  subject  area 

Information  is  at 
risk  of  becoming 
‘old’,  especially  the 
longer  that  the 
individual  is  no 
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longer  practicing 
in  the  area  of 
expertise. 

Lead  Users 

Von  Hippel 
(vonHippel  1982), 
(vonHippel  1988) 

Learn  about  new 
product 
innovations  / 
requirements 
though  users 

Can  give  you  a 
lead  on  the 
competitive 
market 

Difficult  to 
identify,  even 
across  industries 

Quality  Funaion 
Deployment 

Clausing  (Clausing 
1993) 

Systematic  way  of 
mapping  needs  to 
requirements 

Quickly  identifies 
requirements  and 
areas  of 
confliaing 
requirements 

Not  always 
repeatable.  Same 
constraints  can 
lead  to  different 
solutions. 
Dependent  upon 
day  and  people 
participating 

Conjoint 

Dahan  (Dahan 
1998) 

Identifies  relative 
worth  of  needs  in 
relation  to  each 
other 

Quickly  identifies 
those 

requirements  of 
greatest  worth 

Increasing 
complexity  and 
size  of  project 
makes  this 
method  unwieldy. 
However, 
variations  of  this 
method  seem  to 
work. 

Pugh  Method 

Pugh  (Pugh  1996) 

Pools  best  ideas 
of  competing 
concepts  together 
to  determine  a 
better  product 

Very  simple  to  use 
and  understand 

Must  identify  a 
common  datum 
to  reference; 
pooled  concept 
may  not  be 
realistic 

Kano  analysis 

Dahan  (Dahan 
1998) 

Categorization  of 
user  needs 

Allows  product 
development  to 
focus  on 
delivering  the 
‘must  haves’  and 
also  the 
‘delighters’ 

Difficult  to 
initially  categorize 
and  must  manage 
costs  to  improve 
‘delighters’. 

Repertory  Grids 
&  Perceptual 

Maps 

Dahan  (Dahan 
1998) 

Categorization  of 
user  needs 

Identifies  by  shear 
volume  of 
comments  areas 

of  concern  for 

product 

developers 

May  miss  other 
tacit  information 
due  to 

classification 

scheme 

Empathic  Design 

Leonard,  Rayport 
(Leonard  and 

Identification  of 
‘hidden’  needs 

Scaleable  across 
complexity  of 

Difficult  to 
abstract 
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Rayport  1997) 

through 
unobtmsive 
observation  of 
user  and 
environment 

product 
development 
dimension  from 
incremental  to 
market  creation 

information  from 
several  ‘point’ 
observations  and 
generalize  them 
for  the  mass 
market 

Focus  Groups 

Dahan  (Dahan 
1998) 

Structured  session 
where  users  can 
interact  with  one 
another  to  identify 
and  articulate  their 
needs 

Information  can 
be  collected 
quickly  and 
multiple  points  of 
view 

representatives 

Can  degenerate 
into  groupthink. 
May  not  be 
helpful  in  highly 
sophisticated  and 
technical  fields. 

Interviews  & 
Surveys 

Dahan  (Dahan 
1998) 

Individual  specific 
and  focused 
contaa  with  users 
to  identify  needs 

Direa  contaa  and 
feedback  to  users 

Intensive 
coUeaion  effort 
required.  The 
number  of  people 
that  need  to  be 
interviewed  for 
the  sample  to  be 
representative 
may  be  larger  than 
anticipated 

Cultural 

Anthropology 

Takahashi 
(Takahashi  1998), 
Dahan  (Dahan 
1998) 

Observations  of 
users  in  their 
environment  to 
find  hidden  needs 

Very  focused  in 
areas  of  interest, 
most  praaitioners 
are  very  skilled 
and  trained 

Labor  and  time 
mtensive  - 
immersion  into 
users  environment 
takes  longer  than 
other  methods 

Toolkits 

Von  Hippel 
(vonHippel  1999) 

Building  Blocks  of 
different  items 
that  a  user  can 
creatively  use  to 
develop  a  new 
product 

Users  more  likely 
to  prefer  produa 
they  helped 
designed 

Difficult  to  find 
correa  ‘Building 
Blocks’  that  users 
understand  and 

can  use 

Tools  for  the  Front-end  of  Product  Development 

In  addition  to  the  techniques  to  elicit  and  evaluate  user  needs,  there  are  tools  available  to  specifically 
document  the  needs,  their  translation  into  requirements,  and  their  evolution  to  an  end  state.  These 
tools  are  specifically  for  the  overall  activities  of  the  overall  process  in  the  front-end.  These  tools  also 
become  enablers  for  an  effective  process  in  the  front-end,  when  used  correctly.  Among  the  enabling 
tools  available  today  are  the  hundreds  of  modeling  and  simulation  tools.  They  are  too  numerous  to 
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elaborate  upon;  however,  their  place  in  the  overall  process  is  critical^.  The  tools  listed  in  the  table 
below  are  enablers  specifically  for  the  development  of  the  requirements  from  the  user  needs.  They 
help  quantify  what  the  user  means  and  help  translate  those  needs  into  testable  and  understandable 
requirements.  Appendix  C  contains  a  detailed  discussion  about  the  tools  in  the  table.  Note  that  this 
list  contains  just  some  of  the  tools  that  are  commercially  available  for  this  specific  purpose;  it  is  not 
intended  to  be  all-inclusive.  Information  about  each  tool  is  summarized  in  the  table  below. 

Table  7,  Tools  and  Technology  Enablers  for  the  Front-end  of  Product  Development 


Tool  Name 

Overview 

IRSS 

Booz-Allen  &  Hamilton  Inc. 
(Booz-Allen  &  Hamilton  1999) 

Requirements  Management 
System  for  US  Air  Force 

Caliber  RM 

Feibus  (Feibus  1998) 

Client/ Server  Requirements 
Management  System 

IcCONCEPTRTM 

Birkler  (Birkler  1999) 

Client/Server  Requirements 
Management  System 

DOORS 

Birkler  (Birkler  1999),  Feibus 
(Feibus  1998) 

Client/Server  Requirements 
Management  System 

Executive  Information  Systems 

Expert  Choice,  Inc.  (Expert 
Choice  1999) 

Decision  Support  Tool 

DOME 

! 

Wallace  (Wallace  and  Wang 

1999) 

Collaborative  Design 
Environment 

Summary 

The  main  issues  contributing  to  success  are  having  a  process  that  is  holistic  in  nature  and  takes  into 
account  many  broad  objectives.  The  process  should  avoid  waste  in  all  forms,  including  those  areas  not 
typically  thought  of  as  waste.  Development  teams  play  a  large  part  in  the  success  of  the  front-end 
along  with  the  interartion  they  have  with  an  executive  review  committee.  The  vehicle  to  communicate 
with  the  executive  review  committee  is  one  that  is  also  holistic  in  nature  -  a  business  plan.  The 
business  plan  should  address  all  aspeas  of  the  new  product  from  requirements  to  the  organizational 
and  financial  impacts  the  project  will  bring  to  the  enterprise. 

There  is  not  one  way  to  collect,  evaluate  and  understand  user  needs  nor  to  translate  them  into  product 
requirements.  The  method  chosen  to  do  so  depends  upon  the  circumstances  the  enterprise  finds  itself 


5  For  more  information  about  Modeling  and  Simuladon  and  their  criticality  in  the  front-end  of  product  development,  see  (W alton  1999) , 
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in  and  upon  the  environment  in  which  it  must  operate.  Each  method  has  its  advantages  and 
drawbacks.  Clearly,  some  methods  are  better  suited  to  some  front-end  processes  than  others  and  the 
ones  chosen  to  be  used  are  done  so  with  its  advantages  and  drawbacks  in  mind.  It  would  be 
reasonable  to  use  multiple  methods  of  gathering  requirements  to  counter  the  disadvantages  one 
method  might  have. 

Finally,  using  a  tool  that  will  facilitate  communication  among  all  of  the  interested  parties  of  the  front- 
end,  specifically  as  user  needs  are  elicited  and  evaluated,  and  then  transformed  into  product 
requirements  is  essential.  Again,  the  tool  chosen  for  use  must  be  evaluated  against  the  organizational 
form  of  the  enterprise  particularly  in  light  of  the  tools  drawbacks  and  advantages.  These  tools 
underscore  the  importance  of  these  Information  Technologies  as  enablers  to  a  successful  product 
development  process  in  today’s  environment. 

Literature  about  the  Military  Front-end  Process 

Several  pieces  of  material  exist  that  explain  the  theoretical  foundations  of  the  current  system  in  the 
military.  There  is  also  a  great  deal  of  literature  proposing  how  one  group  or  another  would  ‘fix’  the 
system  or  improve  the  various  front-end  processes  of  the  military'®.  Some  of  the  issues  addressed  are 
how  proposed  new  concepts  might  be  identified  as  useful,  how  new-concept  development  and  long- 
range  planning  should  be  funaionaUy  and  organizationally  supported,  and  how  might  new-concept 
development  and  long-range  planning  be  implemented  and  sustained  (Lewis  1995).  The  explicit  topic 
of  Requirements  is  notably  absent. 

Note:  This  section  describes  the  official  view  as  contained  in  the  documentation.  The  “as  is” 
perspective  will  be  presented  later. 

Review  of  ihe  Process  in  the  Military 

To  further  understand  the  context  of  the  process’  existing  shortcomings,  a  brief  review  of  the  process 
is  in  order.  In  general,  the  front-end  process  in  the  military  is  one  where  user  needs  are  transitioned  to 
requirements  for  a  concept  and  readied  for  a  fuU-scale  investment  decision  but  stiU  maintain  the  least 
amount  of  definition  possible  to  allow  for  further  tradeoffs  later  (Laubengayer  and  Spearman  1994). 


Cvirrently,  it  is  one  of  the  most  volatile  issues  in  the  military  community  and  there  are  efforts  tmderwty  that  could  take  action  at  any 
time  and  change  the  focus,  scope  or  mission  of  the  arrrent  system. 
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The  process  begins  when,  at  some  point  in  time,  a  DoD  entity  realizes  it  is  deficient  in  fulfilling  a 
defined  need  or  an  existing  task.  That  need  or  deficiency  begins  a  journey  through  several  processes 
that  hopefully  ends  when  the  deficiency  no  longer  exists.  For  this  study,  the  term  Fuzzy  Front  End 
win  be  used  to  describe  the  portion  of  the  product  development  process  for  the  military  that  ends 
where  the  Acquisition  System"  assumes  control  of  the  development  of  the  material  deficiency.  This  is 
known  as  Milestone  I  in  the  terminology  of  the  Acquisition  System.  The  ‘fuzzy  front  end’  process  is 
run  and  managed  differently  by  the  four  military  services  and  is  executed  differently  within  each 
service  as  well. 

Three  systems  interact  with  each  other  as  part  of  the  overall  irulitaiy  product  development  process. 
These  systems  are  called  the  Planning,  Programming,  and  Budgeting  System  (PPBS)",  the 
Requirements  Generation  System  (RGS)",  and  the  Acquisition  System.  The  input  to  the  system 
usually  begins  at  the  Planning  stage  of  the  PPBS.  After  this  stage,  the  product  development  process 
splits  into  two  different  processes:  Requirements  Generation  and  the  resource  allocation  portions  of 
the  PPBS.  Occasionally,  there  is  some  interattion  between  the  separate  systems,  but  typically  these 
interaaions  are  brief  and  not  scheduled  or  systematic. 

Ideally,  the  output  of  the  Planning  process  is  used  as  a  monetary  input  to  the  PPBS  and  also  as  a  basis 
for  written  requirements  in  the  RGS.  The  Requirements  Generation  System  ideally  uses  and  draws 
upon  those  needs,  deficiencies,  and  potential  solution  concepts  identified  by  the  Planning  Process  to 
develop  the  written  justification  and  direaion  for  beginning  programs  for  acquisition.  The  point  in 
time  where  successful  navigation  of  all  three  of  these  processes  for  a  given  requirement  occurs  is 
known  in  the  military  environment  as  Milestone  Zero,  or  ‘Approval  to  Start  Goncept  Studies’.  In 
simple  terms,  the  Planning  Process  identifies  a  deficiency  (in  the  case  of  the  Air  Force,  the  deficiency  is 
listed  in  its  primary  product,  a  document  called  the  Mission  Area  Plan  (MAP)).  The  RGS  then 
produces  a  document  known  as  a  Mission  Needs  Statement  before  the  PPBS  may  set  aside  money  for 
further  concept  development.  When  the  money  is  available,  the  Acquisition  system  may  assist  with 
concept  development.  Once  concept  development  finishes,  the  RGS  produces  another  document 

The  Acquisition  System  is  the  process  the  military  uses  in  the  full-scale  development  and  fielding  of  a  weapon  system  or  other 

component.  It  begins  with  official  funding  for  beginning  product  development  and  ends  with  the  retirement  of  the  product. 

12  The  system  that  allocates  resources  to  the  various  military  departments  and  services. 

u  The  official  doaimentation  system  that  represents  the  users’  ^.e.  customer’s)  requirements  and/or  need  for  a  system. 


44 


known  as  the  Operational  Requirements  Document  (ORD).  The  PPBS  sets  aside  money  for 
launching  the  development  of  the  system  only  when  the  ORD  is  approved.  This  is  the  point  in  time 
where  the  Acquisition  System  assumes  control  of  the  system  development.  This  point  in  time  is  called 
Milestone  I  or  ‘Approval  to  Begin  a  New  Acquisition  Program’. 

The  Acquisition  System  assigns  a  category  to  a  weapon  system  based  upon  cost.  These  are  usually  a 
combmation  of  development  costs  and  overall  program  costs.  The  Requirements  Generation  System 
uses  the  same  categories  for  managing  the  validation  and  approval  process  for  Requirements 
documents  for  different  weapon  system  programs.  For  instance,  those  Requirements  with  a  large 
dollar  cost  wiQ  be  given  much  greater  scmtiny  than  those  Requirements  with  a  minimal  cost. 

This  diagram  shows  some  of  the  interrelationships  between  the  three  processes. 
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Figure  3.  Process  Interactions  in  the  Front-end  of  the  Military  Product 

Development  Process 

The  figure  above  shows  another  way  to  depia  the  interactions  between  the  three  systems.  A  brief 
overview  of  the  three  processes  will  be  given  to  lay  the  foundation  for  further  analysis  and  discussion 
of  the  Military  Weapon  System  Development  Process. 

Details  about  the  Requirements  Generation  System 

Before  a  potential  concept  can  get  resources  programmed  into  the  budget  or  even  receive  funding,  the 
Requirements  Generation  System  must  produce  a  document  that  Validates’  the  articulated  ‘need’.  A 
high-level  view  of  the  process  to  generate,  validate  and  approve  requirements  is  presented  below. 
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Requirements  Generation  Proeess 


(AFMC  1998)'" 


Figure  4.  Overview  of  the  Requirements  Generation  Process 


The  process  is  directed  by  instructions  from  the  Chairman  of  the  Joint  Chiefs  of  Staff.  This 
instruction  mandates  specific  and  different  activities  that  are  required  for  the  development  of  capability 
shortfalls  and  needs  into  requirements  for  weapon  system  solutions  (CJCS  1999).  The  vast  majority  of 
these  activities  are  the  responsibility  of  the  different  services.  These  activities  that  are  service 
responsibilities  include  conducting  a  Mission  Area  Analysis  and  a  Mission  Need  Analysis.  The 
Instruction  direas  the  format  for  Mission  Need  Statements  as  well  as  the  format  for  Operational 
Requirements  Documents.  It  further  indicates  the  validation  and  approval  process  to  be  used  when  a 


'“I  See  (APMC  1998)  for  detailed  information  about  this  process. 
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requirements  document  needs  to  come  before  the  JROC  for  validation  and  approval.  A  detailed 
process  flow  for  the  process  of  validating  and  approving  a  Mission  Needs  Statement  is  given  below. 
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Figure  5.  JROC  Review  Process 


“The  JROC  assists  the  Chairman  of  the  JCS  (CJCS)  in  making  decisions  and  recommendations  about 
which  weapon  systems  and  other  militaiy  equipment  need  to  be  developed,  bought,  modified,  or 
canceled  in  order  to  meet  the  potential  combat  requirements  of  the  CINCs”  (Smith  1999,  pg.  28).  The 
members  of  the  JROC  are  the  Vice  Chiefs  of  Staff  of  each  of  the  mditaiy  services.  In  all  other  areas, 
the  JROC  gives  the  services  wide  latitude  to  define  and  implement  processes  to  develop  requirements 
and  the  associated  documents  (CJCS  1999).  Virtually  all  needs  and  requirements  are  generated  by  the 
different  services,  although  the  JROC  has  the  authority  to  generate  new  requirements  and/ or  needs 
(i.e.  top-down  directed). 
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The  Joint  Requirements  Oversight  Council  (JROC)  or  another  service  group  (as  in  the  case  of  the  Air 
Force  such  as  the  AFROC  (Air  Force  Requirements  Oversight  Council)^^)  act  as  the  validation 
authority  for  these  documents  -  depending  upon  the  kind  of  requirement.  These  councils  consist  of 
the  senior  leadership  of  the  services.  The  JROC  has  the  ability  to  cancel  or  delay  weapon  system 
development  programs  if  it  feels  the  MNS  is  not  valid.  It  also  has  the  authority  to  internally  generate 
military  requirements  that  the  other  services  have  not  developed  (Salazar  1996).  The  JROC  should  be 
seen  as  being  akin  to  a  corporate  board  of  direaors  that  will  view  rrulitaiy  requirements  holistically  as 
opposed  to  being  parochial  to  their  services’  interests  (Salazar  1996).  James  Blaker,  senior  advisor  to 
the  Vice  Chairman  of  the  Joint  Chiefs  of  Staff,  and  JROC  Chairman,  indicated  the  core  principle  of 
the  JROC  was  “having  the  right  people  address  the  right  issues,  over  the  right  amount  of  time”  (As 
quoted  by  Salazar  1996). 

A  new  Requirements  Document  known  as  a  Capstone  Requirements  Document  (CRD)  has  recently 
been  added  to  the  current  system.  The  purpose  of  this  document  is  to  specify  a  'systems  of  systems’ 
approach  to  meeting  a  validated  need.  The  place  in  the  process  where  the  CRD  fits  is  between  the 
MNS  and  the  ORD.  “The  CRD  captures  the  overarching  requirements  for  a  mission  area  that  forms  a 
family-of-systems  (FoS)  (e.g.,  space  control,  theater  missile  defense)  or  System-of-Systems  (SoS)  (e.g., 
national  missile  defense).  The  ORD  translates  the  MNS  into  more  detailed  and  refined  performance 
capabilities  and  charaaeristics  of  a  proposed  concept  or  system”  (CJCS  1999). 

An  example  of  the  purpose  for  the  CRD  follows.  A  need  has  been  validated  and  approved  on  some 
new  kind  of  threat  detection  system  from  space.  Upon  close  examination  of  the  MNS  need,  it  is 
determined  that  the  need  cannot  be  fulfilled  through  one  system.  In  this  case,  it  may  require  a  series  of 
different  satellites  in  different  orbits,  along  with  several  ground  observation  posts  gathering  different 
types  of  data.  The  need  is  met  only  when  these  systems  work  together. 


>5  “The  AFROC  chairperson  is  the  Direaor  of  Operational  Requirements  (AF/XOR).  The  AFROC  permanent  members  are  the 
MAJCOM  Requirements  principal  0-7/0-8  or  civilian  equivalent,  representatives  from  SAF/AQ  (appropriate  direaorate),  SAF/FM 
(FMB  for  funding  and  FMC  for  cost  issues),  the  Air  Force  agency  whose  need  or  requirement  is  under  AFROC  consideration, 
AFOTEC,  AF/XOI,  AF/IL  (ILM  or  ITS  as  appropriate),  AF/XP,  AF/TE  and  AF/XOC.  Ad  hoc  members’  participants  are  based 
on  topics  under  review.  They  include:  functional  expert  representatives  from  AF/SC,  AF/SG,  and  AF/SP  (representatives  are  not 
limited  to  0-7s/ 0-8s  or  their  civilian  equivalents).  Other  service  representatives  may  be  present  when  joint  needs  or  requirements  are 
considered”  (USAF/DXOR 1999,  pg.  34). 
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A  validated  and  approved  CRD  would  allow  for  the  development  of  several  ORDs  that  would 
contribute  toward  fulfilling  the  need.  The  approval  process  for  the  CRD  is  identical  to  that  used  by 
MNSs  and  ORDs.  The  CRD  is  most  appropriate  for  a  Unified  Command''’  to  write.  At  this  time, 
there  have  been  very  few  CRDs  approved.  For  this  reason,  the  CRD  is  considered  out  of  scope  of 
this  effort. 


JCS  1999) 


Figure  6.  Evolution  of  Requirements  Documents'^ 


The  process  for  the  validation  and  approval  process  of  an  ORD  does  not  change  according  to  the 
‘fidelity  of  the  requirements’  or  the  development  state  of  the  program.  The  revised  ORD  follows  the 
same  process  flow  that  has  already  been  outlined  and  is  changed  only  to  reflect  increasing  detail  about 
the  operational  requirements. 

Each  Unified  Commander  is  tasked  to  develop  an  Integrated  Priority  List  (IPL)  of  requirements  from 
the  commander’s  perspective  to  fulfill  the  mission  and  tasks  that  the  Unified  Command  must  perform. 
These  IPLs  are  to  be  used  in  the  development  of  resource  allocations  within  the  services.  Should 


A  Unified  Command  is  made  up  of  warfighting  units  of  the  different  services  woddng  together.  All  activities  among  the  different  units 
are  coordinated  toward  achieving  the  overall  goal  and  are  led  by  a  single  commander. 

Examples  of  generic  requirements  document  (MNS,  CRD,  and  ORD)  generation  process  is  found  in  Appendix  E. 
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these  not  be  adequately  addressed  in  the  services’  budgets,  the  Joint  process  has  a  forum  called  the 
Joint  Warfighter  Capability  Assessment  QWCA).  This  forum  allows  resourcing  issues  to  be  aired  and 
debated  across  the  services.  This  process  can  directly  influence  the  makeup  of  a  service’s  budget 
request.  It  allows  the  JROC  to  also  influence  the  outcome  of  requirements  development  (i.e. 
approving  or  delaying  requirement  documents). 

A  SWARF  (Senior  Warfighter  Forum)  has  recently  been  added  to  the  joint  process  to  address  issues 
that  specifically  relate  to  requirements  and  do  not  ‘fit’  into  the  overall  purposes  of  the  JWCA  process. 
The  SWARF  allows  Unified  Commanders  to  influence  the  requirements  processes  of  the  services 
from  a  joint  perspective.  “The  SWARF  is  a  JRCX3-directed  forum  used  to  organize,  analyze,  prioritize, 
and  build  joint  consensus  on  a  complex  resource  and  requirements  issue  for  JR-OC  approval.  The 
JROC  tasking  memorandum  will  identify  the  SWARF  lead,  specific  issue  to  be  addressed,  fiscal 
guidelines,  assignment  of  the  appropriate  acquisition  and  technical  expertise  to  frame  issue,  and 
timeline  to  report  recommendation (s).  The  JROC  will  assign  CINCs  to  lead  SWARFs  according  to 
their  missions  and  responsibilities.  The  SWARF  lead  will  brief  the  recommendation(s)  to  the  JROC” 
(CJCS  1999). 

Details  about  the  PPBS 

The  Planning,  Programming,  and  Budgeting  System  is  the  method  by  which  the  military  plans  and 
funds  its  operations.  Although  the  money  for  the  defense  department  is  budgeted  by  Congress  and 
signed  into  law  by  the  president,  the  actual  process  of  building  these  budgets  falls  upon  the  Defense 
Department  -  although  the  Congress  may  determine  to  change  things  during  its  deliberations.  There 
is  added  turbulence  to  this  process  as  Congress  requires  the  DoD  to  submit  a  budget  each  year  for  the 
next  two-year  period.  Therefore,  there  are  always  multiple  cycles  of  the  PPBS  working  at  any  given 
time  of  the  year.  The  Congress  has  never  enacted  a  2-year  budget  for  the  military,  but  the  DoD 
continues  to  comply  with  the  legislation  requiring  it  to  submit  two  years  of  budget  requests.  The 
process  itself  requires  approximately  two  years  once  the  Programming  Phase  begins  to  navigate 
through  all  the  phases  to  reach  the  final  Department  of  Defense  Budget.  Each  service  goes  through 
this  process  of  planning  for  the  future,  programming  (estimating)  future  budgets,  and  actually 
submitting  a  budget  request.  The  Defense  Department  then  consolidates  these  requests  into  a  single 
budget  request.  Within  the  Air  Force,  each  MAJCOM  is  responsible  for  all  phases  of  the  PPBS, 
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although  each  MAJCOM  receives  written  guidance  from  the  Headquarters  Air  Force  about  each  stage 
of  the  PPBS. 
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Figure  7.  The  Planning,  Programming,  and  Budgeting  System 


The  Planning  Phase  begins  by  using  the  National  Strategy  as  communicated  by  the  President  of  the 
United  States.  The  Office  of  the  Secretary  of  Defense  (OSD)  translates  this  strategy  into  the  National 
Militaiy  Strategy.  Additionally,  OSD  releases  its  bi-annual  Defense  Planning  Guidance.  The  individual 
services  release  other  strategic  and  planning  documents,  as  they  deem  necessary.  All  of  these 
documents  are  used  to  determine  the  current  capabilities  of  the  services  and  also  to  help  reveal 
capability  shortfalls. 
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The  governing  instructions  regarding  planning  also  mandate  the  use  of  a  RAND-developed^^ 
methodology  called  ‘Strategy-to-Task’  to  articulate  the  needs,  deficiencies,  and  potential  solutions  that 
may  exist  in  a  mission  area.  The  diagram  below  represents  this  methodology  using  a  building  block 
approach,  with  each  segment  supporting  the  one  above  it. 


(Stewart 


Pg-7) 


1996, 


Figure  8.  Strategy-to-Task  Hierarchy 

As  shortfalls  are  uncovered,  the  Planning  Phase,  with  portions  of  the  Acquisition  community  and 
Requirements  Community,  determine  exactly  how  the  service  plans  to  correct  those  deficiencies 
and/ or  assume  new  mission  areas  as  outlined  in  the  visionary  and  strategic  documents.  At  the  end  of 
the  Planning  Phase,  the  theoretical  visions  of  the  planning  phase  are  represented  by  cost  estimates  for 

RAND  is  a  Federally  Funded  Research  Development  Center  (FFRDC). 
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future  budgetary  action.  The  major  products  from  this  phase  are  some  financial  plans  and  documents 
to  implement  the  vision  and  strategy  given.  One  of  those  documents  is  the  Future  Years  Defense 
Program  (FYDP)  Plan.  The  FYDP  Plan  covers  a  period  of  6  years  beyond  the  immediate  year  in  the 
future.  Theoretically,  there  is  no  limit  to  the  number  of  FYDPs  that  can  be  listed  and  maintained. 
However,  current  guidance  calls  for  maintaining  only  the  next  4  sets  of  FYDPs.  The  Planning  Phase 
does  not  deal  with  the  most  recent  FYDP;  rather,  it  deals  with  the  FYDPs  that  extend  up  to  18  years 
in  the  future.  Other  important  products  are  the  descriptive  narratives  surrounding  each  of  the 
deficiencies  and  proposed  solutions.  These  narratives  are  called  Mission  Area  Plans  (MAPs)  in  the  Air 
Force  and  are  used  as  inputs  to  the  Requirements  Generation  System. 

During  the  Programming  Phase,  the  near-term  FYDP  is  the  focus.  The  first  two  years  of  the  near- 
term  FYDP  are  further  developed  into  the  other  major  product  of  this  phase  -  the  Program  Objective 
Memorandum  (POM).  For  example,  every  year  each  Air  Force  MAJCOM  develops  a  yearly  input  to 
the  overall  Air  Force  POM.  Each  services’  POM  is  reviewed  by  the  Chairman  of  the  Joint  Chiefs  of 
Staff.  The  Chairman  produces  a  document  called  the  Chairman’s  Program  Assessment  (CPA).  It  is  an 
assessment  of  the  services’  POMs,  contains  alternative  recommendations  to  the  service’s  POMs,  and 
prioritizes  requirements  from  the  warfighting  CINCs,  which  is  delivered  to  the  Secretary  of  Defense  to 
assist  the  Secretary  in  making  decisions  on  the  DoD  budget.  The  Secretary  will  also  review  each  of  the 
service  POMs  independently.  The  Secretary  will  take  inputs  from  the  CPA,  the  services’  POMs  as  well 
as  other  advocacy  sources,  like  the  Defense  Planning  and  Resource  Board.  The  Secretary  will  release  a 
Program  Decision  Memorandum  (PDM)  that  contains  the  decisions  of  the  Secretary  regarding  the 
services’  POMs  (Salazar  1996). 

The  last  phase  of  the  PPBS  is  the  Budget  Phase.  This  phase  begins  when  the  services  prepare  a 
Budget  Estimate  Submission  (BES)  based  upon  the  PDMs  received  from  the  Secretary  of  Defense. 
These  BESs  are  submitted  to  the  Office  of  the  Secretary  of  Defense  (OSD)  and  the  Office  of 
Management  and  Budget  (OMB)  for  a  budget  review.  The  CPA  also  exerts  a  great  deal  of  influence 
upon  this  phase.  Upon  completion  of  the  budget  review  OSD  releases  a  Program  Budget  Decision 
(PBD)  back  to  the  services  so  that  the  services  can  modify  their  BESs  for  inclusion  In  the  President’s 
Budget  (PB)  to  Congress  (Salazar  1996). 
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Throughout  all  of  these  process  phases,  there  are  political  maneuverings  going  on  during  the  budget 
building  exercises.  Furthermore,  the  Program  Element  Monitors  (PEMs),  who  manage  a  budgetary 
fundmg  line  item  (such  as  planes,  tmcks,  tanks,  etc.),  often  engage  in  helpful  ‘IF’’  hour  horsetrading’  to 
help  fund  items  important  to  their  warfighting  customers.  Terms  such  as  Offsets  and  other  budgetary 
language  will  not  be  discussed  in  this  effort,  as  it  is  beyond  the  scope  to  do  so.  However,  these 
individuals  are  most  often  responsible  for  building  the  budgets  year  after  year.  They  are,  albeit 
unofficially  documented,  very  important  parts  of  the  PPBS  process. 

Again,  as  these  processes  exist,  they  are  not  static.  At  any  given  time  there  are  four  different  sets  of 
PPBS  aaivities.  The  following  diagram  illustrates  this  concept. 


Planning  FY01-17  (3  FYDPs) 


(18  Years  out ) 


Programming  FY02-  07  (fydp) 


(2-8  Years  out) 


BBS  01  I  PB01  I  POM  02-07  I  BBS  02  |  PB  02  |APOM  03-07 

Summer  Fall  Spring  Summer  Fall  Spring 


(Plummer  1999) 


Figure  9.  Visual  Representation  of  the  Overlapping  Phases  of  the  PPBS 


The  programming  and  budgeting  side  of  the  PPBS  drives  the  outcome  of  the  entire  system.  Without 
money  set  aside  to  fund  the  development  of  a  system  or  the  continuation  of  existing  programs,  these 
things  would  quickly  halt. 


As  an  example,  the  following  graphic’’  shows  the  current  funding  levels  for  the  Air  Force 
(programmed  as  of  1998)  through  FY17  as  well  as  the  implications  of  the  output  of  the  Planning 
processes.  FY  stands  for  Fiscal  Year  (from  October  to  September)  and  CY  stands  for  Calendar  Year. 
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Figure  10.  Air  Force  Defense  Planning  Process  Submission  by  Air  Force 

Core  Competencies 


After  all  of  the  plans  have  gone  through  several  iterations  to  bring  the  estimated  costs  within  the 
budget  guidance  for  the  POM  inputs,  the  years  beyond  the  Future  Year  Defense  Plan  (current  year 
through  the  next  4  years)  show  the  increased  costs  to  finish  each  program.  “Since  the  POM  years 


”  The  heavy  dashed  line  beginning  in  FY05  represents  the  total  inputs  from  each  command’s  MPP.  The  slowly  increasing  line  represents 
a  real  10%  assumed  growth  in  budget  allocation.  By  FY  13,  programs  already  approved  for  fimding  and  in  the  fiuiding  stream  outstrip 
available  resources.  There  is  no  room  for  additional  projeas  or  new  starts  beyond  tliis  date. 
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{cannot}  be  affected,  this  create (s)  a  bow  wave  effect  starting  the  year  after  the  POM  and  continuing 
throughout  the  planning  horizon”  (Weishoff  1990,  pg.  42).  This  graph  shows  the  infamous  ‘bow 
wave’  effect^®  caused  by  stretching,  postponing,  and  changing  programs  from  their  initial  plans.  For 
more  information  about  the  cost  of  these  changes,  see  the  “Cost  of  Delay  Analysis”  section  of 
(McNutt  1998). 

The  Requirements  Process  does  not  remain  dormant  after  a  Mission  Need  Statement  has  been 
approved;  nor  does  the  PPBS.  This  is  because  prior  to  each  Milestone,  a  new  or  revised  ORD  must 
be  validated  and  approved  and  money  must  be  properly  programmed  and  budgeted. 

Details  abcM  the  Acquidtkn  System 

For  most  military  observers  and  also  rrulitaiy  personnel,  a  weapon  systems  development  program 
begins  only  after  getting  through  the  above  mentioned  processes  and  entering  Phase  I  of  the 
acquisition  system.  The  typical  acquisition  process  consists  of  5  phases  that  are  broken  up  by 
milestones.  Two  of  those  milestones.  Milestone  0  and  Milestone  I,  have  already  been  mentioned. 
Acquisition  System  participation  is  limited  in  the  pre-milestone  zero  phase  and  Phase  Zero. 

The  main  aaivity  of  the  Acquisition  Process  during  this  time  is  related  to  the  interface  where  the 
Process  assumes  control  of  the  development  from  the  Requirements  Process  (briefly  at  Milestone  0 
and  then  at  Milestone  I).  This  occurs  when  an  Acquisition  Executive  is  named  as  the  Milestone 
Decision  Authority  (MDA)  and  makes  a  decision  about  the  program.  The  delegation  of  this  authority 
comes  from  the  Secretary  of  Defense  and  has  been  vested  in  the  Defense  Acquisition  Board  (DAB). 
The  DAB  is  made  up  of  senior  acquisition  personnel  (civil  and  military).  The  DAB  wiU  often  delegate 
its  authority  to  the  services  or  to  an  individual,  who  is  called  the  MDA.  When  the  MDA  believes  the 
exit  criteria  established  for  the  Milestone  have  been  met,  and  money  has  been  set  aside  for  the 
program,  the  MDA  can  approve  completion  of  the  milestone.  Upon  approval,  the  process  is  allowed 
to  proceed  into  the  next  phase  of  development.  Nevertheless,  at  Milestone  I  or  Program  Initiation, 
the  Acquisition  System  becomes  the  primary  driver. 


2°  Refers  to  the  existence  of  the  large  budgetary  shortfalls  just  beyond  the  5-year  funding  horizon.  The  bow  wave  analogy  comes  from  the 
notion  of  a  moving  stu^e  prior  to  the  bow  of  a  moving  ship.  In  this  case  the  short  fall  moves  yearly  just  beyond  the  limits  of  the 
current  5-year  plan. 
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The  diagram  that  follows  depicts  the  DoD  Acquisition  ProcessT 
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Figure  11.  Overview  of  Acquisition  Milestones  and  Phases 


All  programs  initiated  by  the  Department  of  Defense  have  an  Acquisition  Category  (ACAT)  assigned. 
Usually,  size  and  complexity  categorize  acquisition  programs.  These  categories  play  a  major  role  in  the 
validation  and  approval  of  Requirements  Documents  in  the  Requirements  Generation  System  because 
a  document’s  ACAT  determines  where  the  validation  and  approval  authority  lies.  The  JROC 
automatically  reviews  all  ACAT  I  documents  and  has  delegated  validation  and  approval  authority  for 
lower  ACAT  documents  to  the  respective  service  chief.  There  are  three  major  acquisition  categories. 
They  are; 


For  a  detailed  review  of  the  mrrent  military  produa  development  process,  see  (McNutt  1998). 
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1.  Acquisition  Category  (ACAT)  I  (usually  MDAPs  (Major  Defense  Acquisition  Programs)) 

2.  ACAT  II  (usually  major  systems) 

3.  ACAT  III  (all  other  acquisition  programs) 

ACAT  I  programs  are  programs  that  are;  “(1)  designated  such  by  the  Under  Secretary  of  Defense 
(Acquisition  and  Technology)  (USD(A&'I))  as  an  MDAP,  or  (2)  estimated  by  the  USD(A&'I)  to 
require  an  eventual  total  expenditure  for  research,  development,  test  and  evaluation  (RDT&E)  of  more 
than  $355  million  in  fiscal  year  (FY)  1996  constant  dollars  or,  for  procurement,  of  more  than  $2,135 
biUion  in  FY  1996  constant  dollars  (10  USC  §243tf^)”  (DoD  1996). 

“ACAT  II  programs  are  defined  as  those  acquisition  programs  that  do  not  meet  the  criteria  for  an 
ACAT  I  program,  but  do  meet  the  criteria  for  a  major  system,  or  are  programs  designated  ACAT  II  by 
the  MDA.  A  major  system  is  a  combination  of  elements  that  shall  funaion  together  to  produce  the 
capabiKties  required  to  fulfill  a  mission  need,  including  hardware,  equipment,  software,  or  any 
combination  thereof,  but  excluding  construaion  or  other  improvements  to  real  property.  A  system 
shall  be  considered  a  major  system  if  it  is  estimated  by  the  DoD  Component  Head  to  require  an 
eventual  total  expenditure  for  RDT&E  of  more  than  135  million  in  FY  1996  constant  dollars,  or  for 
procurement  of  more  than  640  million  in  FY  1996  constant  dollars,  or  if  designated  as  major  by  the 
DoD  Component  Head  (10  USC  §2302(5)'7’  (DoD  1996). 

ACAT  III  programs  are  acquisition  programs  that  do  not  meet  the  criteria  for  an  ACAT  I,  or  an 
ACAT  II  (DoD  1996). 

The  following  diagram  shows  the  relationship  between  the  Requirements  Generation  System  and  the 
Acquisition  System.  The  Requirements  Generation  System  usually  completes  its  aaivities  prior  to  the 
Milestone  decisions. 


22  For  more  information  about  the  above  diagram,  please  see  (AFMC 1998) 

25  Tide  10,  United  States  Code,  2430,  Major  defense  acquisition  program  defined  (these  amounts  have  been  increased  pursuant  to  the 
statutoiy  notice  provided  to  Congress) 

2‘t  Tide  10,  United  States  Code,  2302(5),  Definidons 
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Figure  12.  Requirements  and  Acquisition  Interfaces 


The  diagram  shows  virtually  the  entire  process  to  include  the  further  steps  beyond  the  initial  MNS  and 
ORD  generation.  As  shown  above,  the  overall  Product  Development  process  of  the  military  includes 
mandatory  ORD  revisions  and  multiple  AoAs  (when  determined  necessary  by  the  DAB  or  MDA  at 
each  milestone). 

The  Benefits  of  an  Advanced  Front-end  Process 

Based  upon  the  literature  and  studies  evaluated,  the  benefits  of  having  an  advanced  front-end  process 
are  tremendous.  Saving  $20.5  Billion  per  year  (figure  normalized  to  the  FY2000  $267.2  Billion  DoD 
Budget)  according  to  the  realistic  estimate  made  by  Ganzler,  and  cutting  the  overall  cycle  time  for  the 
front-end  process  will  bring  substantial  savings  to  the  defense  establishment.  Potential  savings  for  the 
Air  Force  alone  amount  to  approximately  $6  Billion  per  year  in  savings  (based  on  FY2000  Budget). 
Furthermore,  an  advanced  front-end  will  provide  higher  quality  requirements  and  higher  fidelity  data 
for  decision-makers.  An  advanced  front-end  is  more  apt  to  produce  projects  that  are  more  likely  to 
succeed  and  are  more  likely  to  correctly  capture  the  desires  of  the  end  user/ customer.  Products  will 
meet  the  needs  for  which  they  were  designed  to  fiU.  Cost  growth  and  requirements  creep  will  be  easier 
to  control.  Projects  will  proceed  through  product  development  processes  smoother  and  easier. 

Drawbacks  to  current  literature 

Other  than  the  limitations  already  discussed  previously,  commercial  sources  generally  don’t  look  at 

large,  capital  intensive,  complex,  and  technologically  advanced  products.  The  only  exceptions  to  this 
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rule  are  those  sources  dealing  specifically  with  the  military  application.  Yet,  none  of  the  military 
sources  connect  the  applicability  of  commercial  processes  and  experience  in  dealing  with  the 
uncertainties  of  the  front-end  to  those  faced  by  the  military  today. 

In  the  commercial  world,  the  Product  Development  topic  is  huge,  yet  front-end  research  is  only  now 
starting  to  emerge.  This  is  an  area  of  great  interest  and  widespread  application.  For  instance, 
Rosenthal’s  material  has  already  been  cited  in  a  journal  used  by  the  Chemical  industiy  (as  being  outside 
the  normal  frame  of  reference).  Cooper’s  work  has  already  been  cited  numerous  times.  Others 
including  Wheelwright,  Clark,  Christensen,  Reinertsen,  Smith,  Rosenau,  etc.,  continue  to  expand  the 
knowledge  of  this  area. 

There  are  two  other  studies  of  the  Military  Requirements  Process  underway.  One  study  is  entering  the 
final  stages  of  its  work  (as  of  this  writing).  Its  first  report  was  issued  in  September  1999 
(USAF/DXOR  1999).  The  final  report  should  be  issued  in  early  summer  2000.  The  General 
Accounting  Office  of  the  US  Congress  is  conducting  the  other  study.  It  should  present  its  findings 
late  in  the  faU  of  2000.  Both  of  these  reports  are  similar  in  design  as  they  assess  the  state  of  military 
requirements  generation  and  compare  these  to  commercial  practices  in  order  to  find  and  determine 
Best  Practices  in  Requirements  Generation.  It  is  hoped  that  these  studies  will  not  have  the  same 
shortcomings  of  the  previous  rmlitaiy  literature.  In  order  to  do  so,  they  should  take  into  account  large 
produas,  a  distributed  ownership  base,  political  forces,  different  ‘customers’  within  the  enterprise,  and 
incorporate  the  latest  research  material  produced  by  academia  and  in  use  in  the  commercial  world. 

Preliminary  Conclusion 

A  systemic  approach  or  holistic  approach  to  the  front-end  of  weapon  system  development  is  needed. 
It  should  be  in  harmony  with  lean  thinking  and  principles.  The  correct  mix  of  processes, 
organizations,  and  tools  will  embody  the  purposes  and  definition  of  lean  in  new  product 
development’s  front  end  and  lead  to  successful  product  development  practices.  As  Acquisition 
Reform  has  made  a  definite  mark  upon  the  way  the  military  does  its  business,  other  areas  for  reform 
have  emerged.  Based  upon  the  current  status  of  the  system,  the  emphasis  for  reform  in  the  military 
must  shift  to  the  front-end  of  weapon  system  development. 
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CHAPTER  3  -  FRAMEWORK  FOR  UNDERSTANDING 

THE  FUZZY  FRONT  END 


Up  to  this  point,  this  work  has  described  issues  surrounding  the  front-end  of  Produa  Development. 
As  a  general  observation,  the  process  area  prior  to  business  case  decisions  or  the  militaiy  Milestone  I  is 
still  somewhat  vague  and  unexplored.  This  seaion  presents  a  framework  based  upon  literature  by 
which  organizations  can  compare  their  front-end  process  against  an  idealized  front-end  process. 
Additionally,  some  useful  metrics  are  given  that  will  help  to  measure  the  performance  of  each 
organization  in  any  area  of  the  framework.  The  idealized  front-end  process  is  by  design  presented  at  a 
high  enough  level  so  that  regardless  of  the  naming  conventions  used,  it  is  applicable  to  the  individual 
needs  and  processes  of  diverse  organizations.  The  framework  also  contains  a  maturity  matrix  by 
which  an  organization  may  determine  where  the  state  of  its  processes  lie  verses  that  of  an  idealized 
process.  Furthermore,  both  the  framework  and  maturity  matrix  seeks  to  address  the  specific 
shortcomings  existing  today  in  both  the  military  and  commercial  processes. 

This  framework  quantifies  and  clarifies  the  paradox  of  organizations  that  are  using  the  most  relevant 
and  useful  methods  of  gathering  requirements  -  methods  such  as  Quality  Funaion  Deployment, 
Conjoint  Analysis  Techniques,  and  many  others  -  but  still  are  unable  to  capitalize  on  the  discovered 
opportunities  in  the  front-end.  Non-exclusive  examples  of  this  include  being  late  to  market,  failing  to 
pursue  potentially  good  product  ideas,  and  producing  a  product  that  is  vastly  different  than  that 
envisioned  during  the  initial  stages  of  development  (a.k.a.  requirements  creep). 

The  framework  consists  not  only  of  an  ideal  process  for  the  front-end  of  Product  Development  but 
also  enablers  that  contribute  to  the  successful  navigation  of  the  process.  The  framework  embodies  a 
‘holistic’  process,  from  implementation  to  integration  with  other  core  business  processes.  The  Process 
for  the  front-end  of  produrt  development  has  four  main  aaivities  or  stages.  The  actual  appearance  or 
names  by  which  these  activities  are  called  within  companies  is  likely  different,  but  the  purposes  of 
these  activities  are  nevertheless  the  same.  The  Enablers  or  Process  Enablers  can  be  broken  down  into 
two  specific  areas:  the  Business  Foundation  Enablers;  and  the  People,  or  Organizational  Enablers. 
This  process  diagram  espoused  by  the  framework  is  similar  to  the  work  done  by  Cooper  and  also 
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Conway  and  McGixinness  but  expounds  upon  the  other  material  presented  in  this  chapter  and  is  more 
comprehensive  than  their  contributions  (Conway  and  McGuinness  1986;  Cooper  1988). 

First,  an  overall  view  of  the  process  will  be  given  and  an  explanation  of  the  activities  in  each  area. 
Following  this,  the  process  will  be  examined  directly  in  light  of  the  two  different  Enablers  -  where  and 
how  they  apply.  Metrics  and  measures  of  performance  will  be  given. 

Finally,  a  relative  scale  of  process  maturity  and  application  of  Enablers  will  be  presented.  This 
framework  wiU  be  used  to  evaluate  the  case  studies  discussed  in  subsequent  chapters  and  also  to 
compare  them  with  each  other.  Validation  of  this  framework  wiU  come  from  using  the  results  of  two 
other  known  studies/ frameworks  that  attempt  to  evaluate/ measure  portions  of  the  front-end. 

The  Process 

Cursory  glance  at  a  graphical  depiction  of  the  overall  process  flow  bears  a  striking  resemblance  to  a 
feedback  matrix.  The  principles  of  feedback  certainly  apply  here.  The  activities  in  these  stages  imply  a 
highly  iterative,  tightly  coupled  mode  of  operation.  The  detailed  nature  of  these  activities  is  discussed 
below.  Each  process  step  relies  upon  the  output  of  the  previous  step  to  proceed,  but  can  also 
influence  any  or  aU  of  the  previous  steps  in  the  process.  Although  the  framework  is  discussed  in  a 
serial  fashion,  it  should  be  noted  that  the  activities  of  the  framework  are  continuous  and  have  only 
been  presented  in  this  fashion  to  facilitate  understanding. 
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The  user  needs/requirements  discovery  process 
(prior  to  a  business  case  decision) 


Figure  13.  The  front-end  framework 

Idendficatim  of ReqtdrenenXs 

The  first  step  in  the  process  of  getting  Requirements  and  User  Needs  can  be  called  Identification.  The 
sources  of  information  upon  which  the  identification  of  user  needs  and  customer  requirements  is 
based  are  extremely  varied.  It  is  essential  that  any  process  design  is  robust  enough  to  accept 
information  from  multiple  sources.  A  few  examples  include  inputs  from  the  marketing  function  in  the 
organization,  the  planning  and  technology  development  funaions,  direct  feedback  from  existing 
customers  and  information  gathered  from  the  market  (i.e.  either  appraisal  of  competitor’s  activities  as 
well  as  trends  within  the  marketplace)  (Frohmna  1978;  Cooper  and  Kleinschmidt  1987;  Leonard- 
Barton,  Wilson  et  al.  1994;  Cooper  1997;  Khurana  and  Rosenthal  1997;  Tabrizi  and  WaUeigh  1997; 
Khurana  and  Rosenthal  1998). 

The  inputs  to  this  stage  are  the  sources  of  the  need  and/ or  requirement.  These  sources  are  extremely 
varied  and  are  not  confined  to  a  specific  list.  However,  the  inputs  can  be  things  such  as  direct 
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consumer  feedback,  market  studies,  research,  and  surveys,  lead  users,  marketing  department  ideas,  top- 
down  management  vision  and  direaion.  There  are  multiple  ways  to  search  for  these  inputs  as  well. 
Understanding  the  different  methods  will  allow  an  organization  to  structure  its  input  gathering 
methods  in  a  way  most  suited  to  its  front-end  process  and  is  also  properly  targeted  and  directed  to  the 
correct  sources  of  information  (Conway  and  McGuinness  1986). 

The  main  process  at  work  is  one  that  sorts,  prioritizes,  and  understands  the  various  process  inputs. 
There  are  several  methods  to  do  this,  such  as  using  QFD,  Conjoint  analyses,  Pugh  analysis,  simple 
categorization  schemes,  etc.  The  key  to  this  stage  is  using  the  proper  kind  of  a  stmctured  method. 
Furthermore,  there  may  be  multiple  methods  that  should  be  used  based  upon  the  strengths  and 
weaknesses  of  each  method  (Dahan  1998).  However,  regardless  of  the  approach  taken,  it  should  be 
one  that  is  consistently  used  and  correctly  applied. 

The  primary  output  from  this  stage  is  an  idea  of  the  true  needs  and  requirements  that  must  be  fulfilled. 
These  are  typically  documented  in  some  form  and  are  done  in  a  manner  that  communicates  to  a 
decision  making  forum  the  necessary  information,  such  as  potential  concepts,  rough  costs  (for 
development,  produaion,  and  lifecycle),  existing  risks,  and  required  technologies.  However,  the  most 
robust  type  of  communication  is  one  that  does  not  specifically  favor  particular  solutions,  nor  solutions 
favored  by  the  vision  of  an  important  customer,  but  should  describe  the  desired  end-state  or  desired 
capability  (Buede  1997). 
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Figure  14.  Visual  representation  of  the  Identification  of  Requirements 

Phase  of  the  Framework 


Some  of  the  specific  enablers  of  this  process  are  the  stmctured  methods  that  help  discover  needs  and 
requirements  that  aren’t  necessarily  apparent.  There  are  many  methods  available  to  do  this.  Some  of 
them  are  Quality  Funaion  Deployment,  Conjoint  Analysis  and  derivations  thereof,  Pugh  Analysis, 
Kano  Analysis,  and  many  others  (Conw^  and  McGuinness  1986;  Kalyanaram  and  Krishnan  1997; 
Dahan  1998;  Dahan  1998).  Therefore,  one  of  the  first  necessary  items  that  are  required  in  this  step  is  a 
structured  forum  that  helps  with  the  elucidation  and  documentation  of  user  needs  and  requirements 
(Buede  1997). 

The  ideal  outcome  of  this  step  is  ideas  that  come  in  a  steady  stream.  A  goal  of  this  step  is  to  foster 

innovation  or  to  provide  a  steady  stream  of  new  products  to  replace  those  that  have  become  or  soon 

will  become  obsolete.  Some  of  the  metrics  for  this  stage  are  the  cycle  time  from  beginning  to  end  of 
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this  stage,  customer  satisfaction  of  the  results  of  this  stage,  possible  patent 
ideas/inventions/copyrights,  and  also  a  stream  rate  (number  of  ‘ideas ’/time)  going  through  the 
process. 

Key  to  the  success  of  this  stage  are  certain  organizational  and  business  elements.  Among  the 
organizational  issues  required  are  the  teams  that  develop  these  ideas  and  user  needs.  Teams  should  be 
small  and  cross-functional  (Smith  and  Reinertsen  1992;  Moenaert,  Demeyer  et  al.  1995;  KJiurana  and 
Rosenthal  1997;  Khurana  and  Rosenthal  1998).  Business  information,  such  as  the  core  competencies 
of  the  organization  along  with  items  such  as  the  vision  of  the  company  need  to  be  well  communicated 
(Cooper  and  Kleinschmidt  1987;  Khurana  and  Rosenthal  1997;  Tabrizi  and  WaUeigh  1997;  Khurana 
and  Rosenthal  1998).  Finally,  tools  and  methods  must  be  used  that  promote  communication  of  ideas 
to  the  next  stage  (Cooper  and  Kleinschmidt  1987;  Khurana  and  Rosenthal  1998).  Without  these 
elements  in  place,  it  is  likely  the  other  activities  in  this  stage,  even  if  correctly  executed,  will  not 
produce  the  results  desired. 

Table  8  contains  metrics  that  are  appropriate  for  the  identification  stage.  Many  of  these  are  intuitive. 
They  should  not  be  the  focus  of  the  stage,  but  part  of  the  overall  process  management  toolkit  for  this 
stage. 

Initial  Screening 

The  second  stage  of  the  process  is  known  as  the  Initial  Screening  stage.  The  input  to  this  stage  (the  list 
of  needs)  should  come  primarily  from  the  identification  stage.  Feedback  from  other  stages  is  always 
welcome  as  inputs.  Here  the  iuputs  from  that  stage  are  further  refined.  This  refinement  consists  of 
explicitly  describing  the  needs  and/ or  requirements  that  a  given  capability  or  potential  solution  might 
address.  This  would  be  done  using  a  document  of  some  kind^^  based  upon  the  activities  of  the 
previous  stage.  This  document  is  really  a  draft  document,  as  later  stages  of  the  process  will  refine  it 
further.  The  document  should,  as  explicitly  as  possible,  describe  the  need  or  desired  capabdily  (Buede 
1997).  Information  regarding  potential  solutions  such  as  development  cost,  development  schedule, 
and  contribution  to  the  enterprise  should  be  listed.  As  this  document  is  drafted  so  early  in  the  front- 
end  process,  this  information  is  expected  to  change  and  be  adjusted.  Any  potential  solutions  to  the 
need  identified  wik  also  describe  the  approach  used  to  achieve  the  goal  (i.e.  the  plan).  This 

25  Or  any  form  of  objea  or  device  that  can  communicate  the  required  information. 
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information  will  address  the  technology  required  -  what  exists  and  what  still  requires  development 
(Frohmna  1978;  Smith  and  Reinertsen  1992;  Moenaert,  Demeyer  et  al.  1995;  Khurana  and  Rosenthal 
1998).  Additional  information  might  be  a  rough  order  of  magnitude  estimate  on  what  the 
development  costs  might  be.  Additionally,  unit  cost  tai^ets  may  be  initially  estimated. 

The  primary  activity  of  this  stage  is  the  colleaion  of  all  of  these  potential  solutions  or  ideas, 
understanding  how  they  address  the  user  need  or  customer  requirement,  and  categorization  into 
multiple  categories  based  on  perceived  risk  and  required  development  (Smith  and  Reinertsen  1992; 
Bacon,  Beckman  et  al.  1994;  Leonard-Barton,  Wilson  et  al.  1994;  Rosenthal  1998).  Knowledge 
management  is  very  important  as  it  capmres  the  key  information  and  competencies  of  the  organization 
and  provides  a  framework  for  its  collection,  organization,  and  dissemination  throughout  the 
organization.  Additionally,  the  portfolio  management  function,  providing  the  organization  with  a 
mixture  of  short,  medium,  and  long-term  solutions,  must  be  active  in  this  stage  as  it  is  essential  for 
success  (Cooper  1996;  Cooper  and  Klelnschmidt  1996;  Rosenau  1997;  Khurana  and  Rosenthal  1998; 
Rosenthal  1998).  At  the  end  of  this  stage  a  decision  is  reached  on  which  potential  solutions  should  be 
pursued  and  those  that  should  not  go  forward.  This  decision  is  based  upon  various  criteria,  such  as 
alignment  with  key  enterprise  goals,  and  fit  with  core  competencies  of  the  organization,  among  others. 
This  constitutes  the  preliminary  screen  or  the  ‘rough  look’  at  an  idea.  A  decision  to  pursue  here  does 
not  mean  a  produa  launch  decision  is  reached  and  massive  company  or  organizational  resources  are 
committed  to  the  projert.  Rather,  it  means  the  committee  or  decision-making  body  feels  that  the  idea 
should  be  further  explored  and  at  this  point  is  a  likely  candidate  to  become  a  new  product.  A  decision 
to  proceed  means  the  ideas  and/ or  solutions  enter  the  next  phase  of  concept  development  (Frohmna 
1978;  Cooper  1997;  Rosenau  1997). 
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end  Framework 


Organizationally,  a  centralized  decision  making  bo<fy  must  be  empowered  to  make  decisions  relative  to 
these  ideas  (Datar,  Jordan  et  al.  1996).  Additionally,  the  body  must  also  have  a  ‘free  rein’  on  their 
portion  of  the  budget.  In  essence,  an  approval  to  proceed  releases  funds  that  will  further  develop  and 
refine  the  ideas.  The  decision  to  proceed  guarantees  the  necessary  resources  for  both  concept 
development  of  the  idea  and  for  preliminary  technology  development  (Gupta  and  Wilemon  1990; 
Cooper  1996;  Cooper  and  Kleinschmidt  1996).  These  funds  are  relatively  small  and  are  better  known 
as  ‘seed’  money  for  promising  ideas.  This  money  is  not  unlimited  and  strict  exit  criteria  are  required 
before  funds  are  authorized  or  approval  to  enter  the  next  phase  is  given. 

The  decision  making  body  should  be  composed  of  senior  individuals  within  the  firm.  These  people 

likely  occupy  several  decision  making  positions  throughout  the  organization.  The  team  needs  to 

remain  relatively  small  and  whatever  method  used  to  reach  decisions  is  agreeable  as  long  as  it  correctly 
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reflects  the  urgency  of  the  need  or  the  time  pressures  of  the  market  (Smith  and  Reinertsen  1992; 
Cooper  1995;  Khurana  and  Rosenthal  1997;  Tabrizi  and  Walleigh  1997). 

A  metric  to  measure  this  stage  is  the  mix  of  long  term  vs.  short-term  potential  projects  that  can  be 
pursued.  This  metric  also  forces  insight  into  the  entire  length  (time  required  to  complete;  the  phasing 
of  new  produa  market  launches;  etc.)  of  the  product  development  process.  The  entire  scope  of 
downstream  activities  must  be  taken  into  account  to  judge  the  proper  time  frame  for  the  product 
introduction.  Additional  metrics  for  the  process  could  be  the  pass/ fail  rate  as  well  as  current  resources 
expended  vs.  the  original  resource  plan  for  the  front-end.  Table  8  lists  some  additional  metrics 
appropriate  for  the  screening  stage.  The  list  is  not  intended  to  be  all-inclusive. 

Concept  DevdopTmt 

The  third  step  of  the  process  is  the  most  familiar  to  most  readers  of  Product  development  literature. 
Here,  research  and  development  is  conducted  into  the  feasibility  of  the  idea.  This  step  is  analogous  to 
the  militaiy’s  Analysis  of  Alternatives  step.  Firm  answers  to  most  unknown  requirements  are  achieved 
during  this  phase  and  are  clear  and  concise  with  measurable  outcomes  and  ranges  clearly  indicated 
(Cooper  and  Kileinschmidt  1987;  Cooper  and  Kleinschmidt  1993;  Cooper  1994;  Cooper  1995; 
Moenaert,  Demeyer  et  al.  1995;  Cooper  and  Kleinschmidt  1996;  Kalyanaram  and  Krishnan  1997; 
Rosenthal  1998).  These  results  are  documented  in  the  draft  plans  that  accompany  this  project. 
Furthermore,  these  plans  become  the  basic  piece  of  the  business  case  for  the  project. 

The  overall  goal  of  this  stage  is  to  further  define  and  explore  the  potential  ‘solution  space’  of  the 
concept  (Cooper  1994;  Bernstein  and  Rebentisch  1996).  As  a  result  of  these  activities,  the  process 
will  come  up  with  the  best  mix  of  ‘requirements’  and/ or  key  objectives  to  be  satisfied.  The  individual 
processes  used  will  likely  mirror  those  used  by  the  first  stage  of  the  process.  Whereas  ideas  may  have 
been  based  on  small  or  cursory  inputs  from  customers  or  the  market,  much  further  definition  and 
exploration  can  be  done.  QFD,  Pugh,  Conjoint  Analyses  can  be  expounded  upon  from  the  first  stage 
(Dahan  1998;  Dahan  1998). 
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Concept  Development  Phase 


The  user  needs/requirements  discovery  process 


Uncertainty  reduction 


Refined 
Needs  & 
Requirements 


Figure  16.  Graphical  depiction  of  the  Concept  Development  Phase 


Beginning  the  process  with  these  structured  methods  and  keeping  the  cycle  time  short  during  the  first 
two  phases  will  allow  the  third  phase  to  build  directly  upon  the  initial  work.  Requirements  should  be 
clearly  specified  in  terms  of  those  requirements  that  are  absolutely  necessary,  those  that  would  be 
desirable  to  have,  and  those  that  would  go  beyond  the  minimum  requirement  and  delight  the  customer 
or  end  user  (Bacon,  Beckman  et  al.  1994;  Cooper  1994;  Cooper  1996;  Huang  1999). 

The  overall  outcome  of  this  phase  is  the  required  information  to  build  a  business  case  for  a  product 
development  launch  decision  (Cooper  1997).  This  required  information  includes  the  architecture  of 
the  product  (whether  existing  or  next  generation),  interfaces  identified  and  possibly  prototyped, 
extensive  use  of  modeling  and  simulation;  and  visions  of  the  overall  customer  support  plan  (lansiti 
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1995;  Ulrich  and  Eppinger  1995;  Khurana  and  Rosenthal  1997;  Tabrizi  and  Walleigh  1997;  Rosenthal 
1998). 


Organizationally,  this  phase  should  be  conducted  by  the  same  team  and  be  given  direction  from  the 
same  management  as  the  first  two  stages  of  the  framework  (G)oper  1995;  Cooper  1996;  Datar,  Jordan 
et  al.  1996;  Tabrizi  and  Walleigh  1997).  This  stage  very  much  mirrors  the  initial  Identification  of 
Requirements  stage.  However,  the  project  has  developed  to  the  point  that  it  has  a  limited  budget  just 
to  explore  the  Requirements  space  of  that  particular  idea.  Furthermore,  studies  and  analysis  are 
encouraged  to  go  much  deeper  than  the  initial  cursory  review  the  idea  received  in  the  Identification 
stage.  The  processes  used  are  much  the  same,  however,  some  project  management  skills  must  be 
employed  to  keep  the  activity  focused  on  the  outcome. 

Metrics  for  this  phase  include  a  reduction  of  ‘unknowns’  in  the  draft  documentation  from  previous 
phases,  the  cycle  time  of  this  phase  in  particular,  as  well  as  the  overall  cycle  time  to  date  (Moenaert, 
Demeyer  et  al.  1995).  Table  8  lists  some  of  these  and  describes  their  appropriate  application. 

Business  Case  Deudopnent 

The  last  phase  consists  of  the  business  case  preparation  and  decision  to  launch  a  product  or  not.  The 
overall  goal  of  this  phase  is  to  explicitly  categorize  and  define  efforts  to  be  pursued  by  the 
organization.  The  input  to  this  phase  comes  direaly  from  the  previous  phase.  It  includes  all 
information  gathered,  including  any  reports  or  studies  conducted  about  an  idea  or  project.  The 
process  to  be  used  during  this  phase  is  typically  one  of  documenting  the  results  of  the  previous  phase 
in  a  manner  that  will  allow  the  decision  makers  to  understand  the  full  implications  of  a  product  launch 
decision.  The  activity  of  documenting  is  resliy  translating  as  much  of  the  team’s  implicit  or  tacit 
knowledge  into  explicit  knowledge. 

Such  information  must  be  presented  with  the  concept  of  employment  of  the  produa  that  corresponds 
to  a  clear  and  concise  description  of  the  product  concept  (Cooper  and  Kleinschmidt  1987;  Cooper 
1994;  Cooper  1995;  Cooper  and  Kleinschmidt  1996).  The  concept  of  employment  is  simply  an 
explanation  of  how  the  product  will  be  used,  and  what  environments  the  product  will  operate  in. 
Also,  in  addition  to  the  information  required  for  a  business  case,  assuming  a  positive  decision,  enough 
information  is  required  for  the  product  development  organization  to  take  the  information  and  get  the 
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new  product  to  market  as  quickly  as  possible  (Cooper  and  Kleinschmidt  1987;  Smith  and  Reinertsen 
1992;  Tabrizi  and  Walleigh  1997;  KJiurana  and  Rosenthal  1998).  The  information  indicates  how  the 
product  is  aligned  with  the  objeaives  of  the  company  and  the  timeframe  of  impacting  those  objectives 
(Cooper  1994;  Murphy  and  Kumar  1996). 

The  plan  will  also  contain  contingency  plans,  such  as  multiple  product  concepts,  alternative 
technologies  developed  in  parallel,  and  sometimes  competing  design  solutions,  to  give  the  organization 
agility  as  the  overall  environment  changes  faster  than  the  overall  product  development  system  can 
reaa  (Khurana  and  Rosenthal  1997).  The  plan  should  also  contain  information  how  the  produa 
replacement  is  planned  and  how  it  forces  the  development  of  replacement  products  with  enough  time 
to  get  into  the  market.  This  information  includes  simple  cost  and  benefit  analysis  to  the  organization. 
This  information  can  be  communicated  through  the  plan’s  comparison  of  the  architecture  of  the 
proposed  product  with  that  current  organizational  standard  or  the  next  generation.  This  comparison 
is  explicit  and  goes  into  great  detail  about  the  similarities  and/or  differences  to  the  existing 
architectures  (lansiti  1995;  Ulrich  and  Eppinger  1995). 
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Figure  17.  Graphical  depiction  of  the  Business  Case  Development  Phase 

of  the  Front-end  Framework 


The  final  result  is  a  decision  to  launch  a  product  and  the  product  development  activities  required  to 
develop  and  deliver  a  final  product.  Such  a  decision  commits  the  organization  to  not  only  the 
product’s  launch  but  also  the  required  resources  to  do  so  (Cooper  1996;  Cooper  and  Kleinschmidt 
1996).  Furthermore,  this  decision  should  be  made  in  an  environment  of  cross-project  understanding 
and  insight  (Frohmna  1978;  Cooper  1997;  Khurana  and  Rosenthal  1997;  Rosenau  1997;  Khurana  and 
Rosenthal  1998).  This  understanding  and  insight  includes  information  about  the  produrt  relationship 
with  other  ongoing  development  projects  in  terms  of  the  values  of  the  affected  resources.  The 
decision-makers  should  also  take  the  opportunity  to  set  the  vision  for  the  product  development 
activities  as  well  as  any  necessary  decisions  on  technology  insertion  (lansiti  1995;  Khurana  and 
Rosenthal  1997). 
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Organizationally,  the  decision  making  body  must  have  the  authority  to  commit  the  resources  of  the 
organization  based  upon  the  information  in  the  business  case.  This  decision  should  also  mark  the 
formal  entry  of  the  product  into  the  product  development  process  of  the  organization,  whether  it  is  a 
typical  stage-gate  process  or  another  type  of  process. 

Metrics  for  this  stage  include  a  mixture  of  typical  business  metrics  as  well  as  product  and  process 
metrics.  These  include  the  number  of  product  features  (funded  vs.  unfunded).  Return  on  Investment, 
Net  Present  Value,  Cycle  time  of  the  entire  process.  Time  since  the  last  product  revision,  time  since 
the  last  revision  of  the  produa  vision  (typically  no  more  than  two  years). 

Process  Enablers 

It  is  appropriate  to  begin  a  discussion  about  the  enablers  of  the  process.  They  have  been  alluded  to 
throughout  this  section.  Now  they  will  be  discussed  in  depth.  Some  of  these  enablers  operate  across 
or  span  the  entire  process  and  it  is  not  appropriate  to  try  and  partition  them  into  one  of  the  four 
process  steps.  Others  are  very  specific  to  certain  steps  and  will  be  treated  accordingly. 
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Business  Foundation 


Organiiatimal  Enablers 

This  section  will  describe  the  ‘to  be’  (or  Best  Practices)  desired  state  of  the  product  development 
organization.  The  overall  focus  of  the  organization’s  people  is  on  understanding  user  needs.  The 
goals  and  strategy  of  the  organization  are  known  and  understood  by  all  employees  and  is  explicit  for 
the  front-end  of  product  development  (Cooper  1996;  Cooper  and  Kleinschmidt  1996).  They 
understand  how  their  specific  job  relates  to  achieving  those  goals. 

The  organization  is  structured  to  automatical^  generate  cross-functional  inputs  (Cooper  1994;  Cooper 
and  Kleinschmidt  1996).  This  is  done  through  the  use  of  small  teams,  such  as  Integrated  Product 
Teams  whose  members  represent  various  backgrounds  (Smith  and  Reinertsen  1992),  allowing  these 
teams  to  negotiate  their  roles  and  responsibilities  prior  to  beginning  the  front-end  process  (Khurana 
and  Rosenthal  1997;  Tabrizi  and  Walleigh  1997),  and  encouraging  teams  to  form  on  a  self-selecting, 
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spontaneous  basis  (Gupta  and  Wilemon  1990;  Cooper  and  Kleinschmidt  1995;  Cooper  and 
Kleinschmidt  1996).  Rather  than  restrict  employee  participation  in  the  front-end,  it  should  be 
encouraged  and  not  restricted  when  actively  engaged  on  a  project  for  the  front-end  (Smith  and 
Reinertsen  1992;  Cooper  and  Kleinschmidt  1996;  Khurana  and  Rosenthal  1997).  Finally,  the  team 
should  remain  intact  for  the  entire  front-end  process  and  leadership  of  the  team  should  be  placed  in 
senior  individuals  who  have  done  well  in  technical  and  managerial  skill  evaluations  (Cooper  and 
Kleinschmidt  1987;  Smith  and  Reinertsen  1992;  Cooper  1994;  Cooper  1994;  Leonard-Barton,  Wilson 
et  al.  1994;  Cooper  1995;  Cooper  and  Kleinschmidt  1996;  Tabrizi  and  Walleigh  1997).  The  team 
consists  of  a  small  ‘core’  group  that  can  draw  upon  a  larger  periphery  of  other  teams/functional 
groups. 

Business  Foundation  Enablers 

An  absolute  requirement  for  the  business  environment  of  the  organization  is  the  establishment, 
measurement  and  adherence  to  a  formal  front-end  process  (Cooper  and  Kleinschmidt  1987;  Cooper 
1994;  Cooper  1996;  Cooper  and  Kleinschmidt  1996).  One  organization  should  be  responsible  for  the 
front-end  of  product  development  (Cooper  1996;  Datar,  Jordan  et  al.  1996).  There  is  a  distinct  lack  of 
organizational  layers  between  management  and  the  front-end  process.  Ideally,  the  same  organization 
that  does  the  front-end  of  product  development  also  controls  the  entire  produrt  development  process 
(Khurana  and  Rosenthal  1998)  (Khurana  and  Rosenthal  1997). 

Executive  Reviews  are  done,  but  management  plays  a  different  role  than  accustomed  to,  that  of  coach 
and  advisor,  not  decision-maker  (until  the  screening  and  business  case  decisions  have  to  be  made  - 
then  they  are  accountable).  The  reviews  are  conducted  to  give  insight,  not  necessarily  direction  (Smith 
and  Reinertsen  1992;  Cooper  and  Kleinschmidt  1996;  Karlsson  and  Aehstroem  1996;  Buckler  1997; 
Khurana  and  Rosenthal  1998).  Built-in  ‘triggers’  force  decisions  to  be  made  before  proceeding  with 
further  development.  These  triggers  allow  management  to  resume  its  familiar  role  of  decision  making. 
The  ‘triggers’  in  the  framework  are  found  at  the  initial  screening  stage  and  also  the  business  case 
decision.  Application  of  this  concept  should  be  extended  well  into  the  typical  phase  gate  product 
development  system  of  the  organization  (Frohmna  1978). 

Once  started,  programs  are  ensured  stability  in  schedule  and  money.  This  requires  dedication  on  the 
part  of  the  business,  as  well  as  an  understanding  of  the  importance  of  the  investment  decisions  (and 
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ties  directly  into  the  people  and  organizational  enablers  previously  discussed)  (Tabrizi  and  Walleigh 

1997) .  Portfolio  management  must  take  into  consideration  the  balance  between  resource  capacity  and 
process  flexibility.  This  includes  understanding  the  relationship  between  project  development  speed 
and  resource  starving  projects,  as  well  as  the  relationships  between  short-term  and  longer-term 
projects  (Leonard-Barton,  Wilson  et  al.  1994;  Khurana  and  Rosenthal  1997;  Rosenau  1997). 

Programs  require  complete  and  explicit  definitions  (i.e.  good  requirements).  In  this  way,  programs 
avoid  unnecessary  changes  and  enjoy  stability  in  their  plans  and  strategy  (Khurana  and  Rosenthal 

1998) .  This  includes  tightly  coupling  the  efforts  of  the  R&D  organization  with  the  current  product 
concepts  within  the  front-end  (Cooper  and  Kleinschmidt  1996).  A  common  database  or  requirements 
management  tool  is  essential  to  fostering  communication  from  one  stage  to  the  next,  and  ultimately 
into  the  full-blown  product  development  process  (Gupta  and  Wilemon  1990;  Khurana  and  Rosenthal 
1997). 

Technical  competency  of  the  workforce  is  essential  to  success.  A  Robust  training  program  in 
functional  depth  and  organizational  breadth  is  required  to  keep  people  in  the  front-end  of  new 
product  development  aware  of  and  knowledgeable  of  new  technology,  techniques,  and  processes 
applicable  to  new  product  development  (e.g.  market  research)  (Cooper  and  Kleinschmidt  1987; 
Cooper  1996). 

Core  competencies  are  identified  and  strengthened  by  the  organization’s  management.  Although  the 
methods  to  identify  and  strengthen  these  competencies  are  varied,  the  core  competencies  should 
embody  the  essence  of  the  organization:  the  activities,  capabilities,  and  resources  that  are  either  unique 
to  the  organization  or  are  key  to  the  success  and  well  being  of  the  organization.  Management  vision 
and  involvement  built  upon  these  competencies,  are  well  articulated,  and  communicated  to  all 
employees. 

Process  Metrics 

The  following  table  indicates  those  metrics  that  apply  to  the  different  stages  of  the  framework  and  also 
the  enabling  practices.  Those  metrics  that  appfy  to  each  stage  are  considered  to  be  key  metrics  that  are 
to  be  used  to  assess  the  overall  condition  of  the  front-end  process. 
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Table  8.  Front-end  Process  Metrics 


Number  and 
length  of  supplier 
relationships  over 
time  (number  & 
time  -  days,  weeks, 
months  -  as 

appropriate) _ 

Seniority  of  Team 
(years,  experience) 


Portfolio  mix  (Mix 
of  solutions  into 
near,  mid,  and  far 


Desired  trend 

Frequency  of 
Update 

Downward 

Continuous 

Upward 

Monthly,  or  less 
frequent 

Steady  or  constant 

Continuous 

Downward 

Each  phase 

Downward 

Each  phase 

Steady  or  constant 

Each  phase 

Steady  or  constant 

Each  phase 

Steady  or  constant  at  an 
agreed  upon  level  (i.e.  3 
years  with  high  standard 
deviation  -  implies 
experienced  leadership 
and  also  young  employees 
being  trained) 

Each  phase 

Steady  or  constant 

Monthly 
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categories) 

■ 

■ 

■ 

Cycle  time  of 
product  releases 
(time  -  days, 
weeks,  months  - 
as  appropriate) 

1 

1 

1 

1 

1 

1 

Steady  or  constant 

Yearly 

Percent 
commonality 
across  different 
products 
(percentage) 

1 

1 

Upward 

Yearly 

Return  on 
Investment  (value 
in  units  of 
currency) 

1 

1 

1 

1 

1 

1 

Steady  or  constant 

Each  project 

Net  Present  Value 
(in  units  of 
currency) 

1 

1 

H 

1 

Steady  or  constant 

Each  projea 

■ 

U 

■ 

II 

■ 

II 

Steady  or  constant 

Each  phase 

‘Successful’ 
projects  vs.  failures 
(ratio) 

1 

1 

1 

i 

1 

i 

Steady  or  constant 

Each  project 

Number  of  rework 
cycles/ feedback  (a 
number) 

i 

i 

I 

I 

I 

i 

Downward 

Yearly 

Number  of 
outstanding 
produrt  features 
vs.  those  built  (A 
ratio) 

1 

1 

1 

1 

1 

1 

Steady  or  constant 

Each  project 

Time  elapsed  since 
product  vision 
updated  (time 
elapsed) 

1 

1 

1 

1 

1 

1 

Steady  or  constant 

Yearly 

Ratio  of 

Obligations  to 
Budget  (ratio) 

1 

i 

1 

i 

1 

i 

Stream  rate  {#  of 
ideas  vs.  time  - 
days,  weeks, 
months  -  as 
appropriate) 

1 

Steady  or  constant 

Monthly 

Phase,  S4  =  Business  Case  Development  Phase,  O  =  Organizational  EnaHers,  B  =  Business 
Foundation  Enablers 
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Understanding  the  relationships  among  these  metrics  can  lead  to  leveraged  advantages.  For  instance, 
many  of  the  business  process  enablers  are  also  prevalent  in  the  screening  stage  and  in  the  business  case 
decision  stage.  These  metrics  are  understandably  more  ‘business’  and  business  decision  oriented.  The 
key  understanding  is  that  these  typical  business  metrics  apply  only  to  those  two  portions  of  the 
framework,  and  specifically  to  the  potential  projects  under  evaluation.  Other  metrics  should  be  used 
to  assess  the  ‘health’  of  the  other  stages  of  the  front-end  process. 

Best  Practices  Spectrum/Maturity  Matrix 

The  following  tables  present  the  spectrum  of  process  activity  found  within  New  Product 
Development.  These  tables  will  allow  organizations  to  evaluate  the  ‘maturity’  of  their  own  processes 
vs.  an  ideal  front-end  of  product  development.  Graphical  depiaions  of  the  same  information  will  also 
very  quickly  convey  a  sense  of  an  organization’s  process  relative  to  other  organizations. 

The  matrix  has  a  spectrum  of  performance.  An  organization  that  finds  its  process  practices  are  best 
described  by  the  definition  given  in  Level  1  have  a  Least  Mature  Process.  Alternatively,  an 
organization  that  is  best  described  by  those  definitions  given  in  Level  4  have  a  process  that  is  Most 
Mature.  It  is  possible  for  an  organization  to  not  identify  with  any  definition  at  all.  In  these  cases,  there 
is  Hkely  no  process  at  all  in  place  or  the  process  is  in  an  emergent  state.  Also  organizations  may  have 
multiple  praaices  that  span  a  range  of  levels.  This  is  expected.  Every  organization’s  process  is  in  a 
different  state  of  maturity  and  the  path  of  improvement  for  each  organization’s  process  is  different. 

The  level  definitions  were  developed  by  closely  examining  the  practices  identified  in  the  literature  and 
extrapolating  degrees  of  ‘goodness’  that  reflect  how  much  a  particular  practice  or  concept  has  been 
implemented  in  an  organization’s  front-end  process.  This  information  was  used  to  create  the  different 
descriptions  for  each  level.  Ensuring  that  the  differences  reflected  in  the  descriptions  for  each  level 
were  measurable  and  not  just  open  to  interpretation,  the  matrix  was  populated.  Additionally,  the 
element  descriptions  were  iterated  during  data  collection  and  analysis,  helping  to  ground  the 
framework  in  empirical  observations.  The  maturity  matrix  is  not  intended  to  be  all-inclusive  or 
complete.  As  additional  Best  Practices  emerge  and  are  found,  they  can  be  placed  within  the  matrices 
at  the  most  appropriate  locations. 
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Table  9.  Maturity  Matrix  for  the  Identification  of  Requirements  Stage 


Table  10.  Maturity  Matrix  for  the  Screening  Stage 
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CHAPTER  4  -  RESEARCH  DESIGN 


This  chapter  discusses  the  approach  of  the  research,  the  key  questions  to  be  answered,  how  the 
research  will  be  performed,  and  explains  the  primary  deliverables.  Additionally,  a  discussion  about 
research  validity  and  the  population  and  sample  of  the  research  will  be  given. 

Population  and  sample 

The  sample  population  group  of  this  stucfy’  includes  the  major  Air  Force  Commands  as  well  as  other 
Air  Force  officials  at  the  Pentagon^^.  Among  the  other  services,  those  branches  that  deal  primarily 
with  developing  requirements  for  aerospace  vehicles  are  also  considered,  although  other  areas  of  these 
services  will  be  examined  for  additional  insight.  Therefore,  the  samples  from  the  military  include  each 
of  the  services,  and  four  Unified  Commands,  for  a  total  of  eight  miKtary  organizations. 

The  samples  from  industry  include  chemical  application  companies,  commercial  airline  companies, 
other  aerospace  companies,  and  computer  industry  companies  for  a  total  of  8  companies.  These 
companies  were  specifically  chosen  for  a  variety  of  reasons.  Two  of  the  companies  were  specifically 
recommended  for  study  by  consultants  who  have  done  front-end  evaluations  and  indicated  that  these 
were  among  the  most  advanced.  The  computer  companies  were  included  in  the  sample  because  of  the 
rapid  cycle  times  of  new  technology  and  product  obsolescence,  which  the  US  Military  faces  as  a 
constant  threat  as  well.  The  Airlines  were  included  because  they  represented  end  user  organizations 
similar  to  the  Military’s  Unified  Commands  and  they  both  need  and  must  use  highly  complex, 
technical  products  to  do  their  jobs.  Finally,  several  aerospace  companies  were  included  because  they 
are  in  the  same  domain  space  as  the  US  Air  Force,  and  are  typically  similar  to  the  US  Air  Force  in 
deafing  with  highly  expensive,  very  complex  produa  development  issues. 

One  more  sample,  a  foreign  military,  is  included.  This  military  organization  was  included  in  the 
sample  because  of  the  different  w^  it  approaches  product  development;  it  is  in  many  respects  a  hybrid 
of  the  commercial  and  military  organizations. 


26 


Depending  upon  the  commercial  aerospace  compaty  chosen,  another  AF  command  may  be  chosen  for  study  for  better  alignment 
across  business  markets/ areas. 
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Study  Design 

The  preferred  method  of  study  was  the  case  stucfy.  There  were  multiple  case  studies  to  ensure  the 
general  applicability  of  this  work.  This  work  relied  upon  purposive  sampling  in  data  gathering  and 
building  of  the  cases.  The  case  stucfy-  method  was  more  appropriate  as  most  of  the  questions  asked  in 
this  research  were  of  the  ‘how’  and  ‘why’  variety.  This  topic  could  also  not  be  manipulated  in  events 
to  meet  experimental  criteria. 

The  primaiy  source  of  data  was  from  the  US  Air  Force  as  well  as  other  field  research  in  both  the 
military  and  commercial  arenas.  The  key  questions  helped  bring  ‘Best  Practices’  to  light,  wherever  they 
were,  and  helped  assess  the  idea  that  a  systematic  process  is  superior  to  an  ad  hoc  one. 

Mapping  the  existing  needs/ requirements  generation  process  was  accomplished  through  an  extensive 
review  of  the  Hteramre  and  also  interviews  of  key  players  within  the  system.  This  approach  was  used 
for  all  of  the  services  and  commercial  industry  examples. 

Similarly,  through  interviews,  personal  communication  with  key  players  and  existing  literature,  data  was 
collected  that  serves  to  give  a  qualitative  look  at  the  effeaiveness  of  their  processes.  These  were 
compared  to  the  existing  theory  and  the  results  were  also  charaaerized. 

An  idealized  front-end  process  was  developed  and  then  using  these  case  studies,  the  organizations 
were  compared  against  this  idealized  front-end.  The  idealized  process  came  from  the  literature,  but 
was  also  validated  in  some  sense  by  the  field  observations.  As  the  idealized  front-end  process 
describes  practices  for  the  front-end,  these  practices  were  then  translated  into  concise  policy  initiatives, 
that  when  undertaken,  should  yield  results  similar  to  those  described  in  the  literature  and  other 
research.  The  degree  of  implementation  of  the  practices  advocated  in  the  process  maturity  matrix 
characterizes  the  organization’s  “leanness”  of  its  fuzzy-front  end  aaivities^^. 

Methods 

The  main  method  of  research  used  to  collea  the  data  was  the  personal  interview.  Three  other  sources 
of  information  included  documentation  (prepared  briefings  and  presentations  as  well  as  other 
documents,  such  as  Military  Regulations  and  Instmaions  and  company  plans),  direct  observation  and 


27  Lean  meaning  the  right  things,  at  the  right  time  and  place,  in  accordance  with  the  Lean  Enterprise  Model  and  other  Lean  Material. 
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participant  observation  (through  the  author’s  participation  on  the  HAF  2002  Requirements 
Reengineering  Team). 

Over  325  people  were  interviewed,  of  which  nearly  300  were  specifically  done  as  part  of  the  HAF 
2002  Requirements  Reengineering  effort.  The  author  did  not  interview  all  of  these  people  (only  about 
50  personally  for  the  HAF  2002  effort),  but  the  materiel  gathered  (notes,  papers,  briefings)  from  all  of 
the  interviews  by  HAF  2002  matched  the  requirements  of  this  work.  As  a  member  of  the  core  team 
for  the  HAF  2002  Requirements  Reengineering  effort,  the  author  had  access  to  a  tremendous  amount 
of  data  for  this  thesis.  The  vast  majority  of  those  interviewed  by  the  HAF  2002  effort  were  employed 
in  positions  relating  to  the  US  Air  Force  or  the  different  US  Military  services.  About  1/3  of  those 
interviewed  held  high  positions  of  authority  in  their  respective  companies  or  organizations  (e.g.  a 
three-star  general  or  vice  president  position)  in  addition  to  the  many  lower  level  personnel  who  were 
interviewed.  For  the  purposes  of  the  US  Air  Force  Case,  interviews  were  conducted  at  every  Major 
Command  that  generates  requirements.  Additionally,  interviews  were  conducted  with  Air  Force 
Organizations  that  either  reviewed  requirements  documents  or  approved  them.  Finally,  interviews 
were  conducted  with  individuals  within  the  US  Air  Force  Acquisition  community  that  were  the  end 
users  of  these  documents.  Therefore,  the  case  study  done  on  the  US  Air  Force  is  much  more 
comprehensive  than  the  other  case  studies. 

The  interviews  conducted  by  the  HAF  2002  effort  were  conducted  to  specifically  assess  the  current 
state  of  the  existing  Requirements  Process  in  the  interviewee’s  respective  organizations.  AH  of  the 
interviews,  including  those  done  specifically  for  this  effort,  were  stmctured  to  gather  as  much 
information  as  possible  about  each  organization’s  front-end  process.  AvaHable  documentation  of  any 
kind  was  used  to  further  determine  the  organization’s  front-end  process.  CaUbacks  and  additional 
visits  were  used  where  not  enough  information  was  gathered. 

Upon  receiving  the  information  for  each  organization’s  process,  the  author  began  the  process  of 
organizing  and  categorizing  the  information.  This  information  was  primarily  used  to  write  each 
organization’s  case  study.  The  case  studies  were  made  available  to  the  companies  for  review  to  ensure 
accuracy  of  the  noted  observations.  Most  suggestions  offered  by  these  companies  were  not 
substantially  substance  oriented,  but  focused  more  upon  clarification  of  process  aaivities. 
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During  the  course  of  preparing  the  case  studies,  the  author  also  scored  the  organiTations  against  the 
process  maturity  matrix.  To  maintain  a  sound  approach  to  the  scoring,  each  element  of  the  matrix  was 
assigned  a  score  of  one,  two,  three,  or  four  points  respectively,  depending  upon  which  level  of  the 
matrix  the  element  was  in.  This  method  was  chosen  to  give  the  author  the  flexibility  to  score  elements 
in  each  matrix  differently  to  reflect  the  various  and  different  practices  found  within  each  organization. 
For  instance,  a  company  could  have  a  very  good  practice  (Level  4)  and  an  equally  poor  practice  (Level 
1)  existing  in  the  same  phase  of  the  front-end.  In  this  case,  if  the  phase  had  only  two  elements,  the 
overall  score  for  that  phase  for  that  organization  would  be  2.5  (4  plus  1  equals  5,  divided  by  the 
number  of  elements  in  the  matrix  (in  this  case,  two)).  The  current  maturity  matrix  contains  37 
elements,  separated  into  six  different  categories,  reflecting  the  four  process  phases  and  the  two  process 
enabling  factors.  Organizational  and  Business  Enablers. 

At  the  outcome  of  this  scoring  exercise,  the  resulting  data  was  sorted  and  ranked.  The  outcome 
showed  that  commercial  companies  consistently  outperformed  the  military  organizations.  This  was  of 
no  surprise  as  it  reflected  the  field  observations  of  all  of  the  organizations  in  this  study. 

Upon  completing  the  writing  of  the  case  studies,  the  entire  scoring  process  was  redone.  This  was 
done  for  two  reasons.  The  first  reason  was  to  ensure  that  any  information  that  was  not  available  prior 
to  finishing  the  case  study  write-ups  could  be  included  in  the  matrix  scoring.  The  second  reason  was 
to  make  sure  that  all  of  the  data  was  scored  at  the  same  time,  under  the  same  conditions,  in  order  to 
minimize  any  other  environmental  effea.  The  results  of  this  scoring  largely  mirrored  the  first  round 
of  scoring,  although  there  were  a  few  changes  reflected  in  the  outcomes,  usually  in  an  organization 
moving  up  or  down  by  one  or  two  places  in  the  matrix  rankings. 

After  receiving  feedback  from  the  companies  on  their  case  studies,  the  process  was  scored  again  from 
scratch,  for  the  same  reasons  as  the  second  round  of  scoring.  The  outcomes  of  this  round  substianted 
the  second  scoring  round.  A  few  adjustments  were  made  to  the  process  matrix,  in  the  form  of 
clarifications  and  internal  validity,  that  would  make  it  easier  for  the  general  reader  to  interpret  the 
matrix  the  same  way  as  the  author.  Those  matrix  elements  that  were  affected  were  rescored  to  ensure 
the  results  were  reasonable  to  the  element  description.  These  few  adjustments  and  the  last  overall 
scoring  round  constitued  the  final  scoring.  Upon  review,  the  final  scoring  outcomes  were  stable  in 
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comparison  with  the  previous  efforts.  This  information  forms  the  basis  of  the  data  analysis  and 
discussion  presented  in  chapter  7. 

The  method  of  scoring  described  above  ensures  the  represented  data  is  valid,  particularly  due  to  the 
process  method  and  the  safeguards  in  place.  Additional  reasons  for  the  validity  of  the  data  stem  from 
the  fact  that  similar  organizations  (e.g  airlines,  the  Unified  Commands,  the  Services,  etc.)  received 
similar  scores  independent  of  any  a  priori  comparison.  The  final  reason  for  lending  validity  to  the 
outcomes  presented  in  the  data  analysis  and  discussion  chapter  stems  from  two  independent  reports 
published  by  two  different  consulting  companies.  The  reports  produced  by  those  companies  contain 
some  of  the  same  organizations  evaluated  in  this  report  (both  miHtaty  and  commercial),  and  their 
report  conclusions  are  similar  to  those  (for  the  organizations  common  between  the  reports)  presented 
in  this  work.  The  top  firms  reported  by  these  studies  were  the  top  performers  in  the  maturity  matrix 
and  there  is  a  correlation  of  outcomes  between  these  studies  and  this  work,  even  though  the  methods 
used  to  determine  the  outcomes  were  different  (i.e.  this  work’s  maturity  matrix  vs.  entirely  different 
frameworks  in  the  two  studies). 

CXher  research  alternatives  considered 

Among  the  qualitative  research  variations  available,  a  survey  was  considered  but  was  not  chosen 
because  it  was  not  clear  exactly  to  whom  the  survey  should  be  targeted  or  who  the  players  in  the  front- 
end  process  actually  are.  It  was  only  during  the  interview  process  that  contacts  were  made  with  the 
individuals  to  whom  this  research  was  most  suited.  Furthermore,  the  nature  of  this  research 
demanded  access  to  policy-making  individuals  and  those  with  either  process  ownership  or  deep 
understanding.  At  the  time  of  this  undertaking,  access  to  these  individuals  was  impossible  to  secure. 
Through  the  participation  on  the  Headquarters  Air  Force  2002  Reengineering  Team,  access  to  these 
individuals  was  cleared  (both  within  the  military  and  also  from  commercial  organizations,  who  were 
more  attentive  to  an  effort  by  the  Headquarters  Air  Force).  Finally,  the  overall  process  of 
requirements  generation  is  currently  the  subject  of  much  attention  and  it  was  not  clear  what 
information  would  be  or  should  be  collected:  historical,  current,  or  data  concerning  a  newer  system 
being  contemplated. 
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Concerns  about  Research  Validity 

While  the  research  design  determines  the  validity  of  the  results,  there  are  issues  that  may  effect  the 
applicability  of  the  research.  Because  of  the  volatility  in  the  system  at  this  time,  any  changes  made  to 
the  system  could  affect  the  applicability  of  the  results.  This  is  known  as  the  ‘history  effect’.  This 
appears  to  be  the  single-most  serious  threat  to  the  applicability  of  this  research. 

Of  course,  every  effort  was  made  to  avoid  some  of  the  more  common  threats  to  the  validity  of  this 
kind  of  research.  These  threats  apply  to  the  principal  methods  employed  in  the  research.  These 
include  poor  methodology,  lack  of  generalizability,  and  meandering  write-ups.  Frequent  interaaion 
with  the  thesis  advisor,  along  with  multiple  peer  reviews  of  the  research,  contributed  to  ensuring  valid 
research  design. 

An  additional  concern  existed  due  to  the  participation  of  the  author  on  an  Air  Force  team  charged  to 
'reinvent'  the  Requirements  Process.  The  author  could  have  become  too  'involved'  in  the  outcome  of 
the  effort  and  bias  the  results  of  the  research.  However,  the  implications  of  a  synergistic  relationship 
between  the  purposes  of  this  team  and  this  research  were  compelling.  This  relationship  allowed  this 
research  to  build  upon  the  work  of  this  team,  as  long  as  the  methods  employed  withstood  the  scrutiny 
of  academia  (rigor,  internal  and  external  validity,  etc.).  One  safeguard  in  place  was  the  use  of  a 
database  of  all  related  activities  and  existing  literature.  Documentation  was  gathered  through 
interviews,  direa  and  participant  observation,  and  using  source  material,  which  was  used  to  establish  a 
‘causal  chain  of  evidence’  for  the  case  studies.  Explanation-budding  continued  to  build  causal  chains 
of  evidence  and  was  used  to  test  hypotheses.  Additional  safeguards  included  the  close  supervision  of 
this  work  by  the  thesis  advisor.  A  final  barrier  to  assimilation  existed  in  the  geographic  separation 
between  the  author  and  the  rest  of  the  Air  Force  team  (located  in  the  Washington  DC  area). 

The  individual  cases  are  addressed  in  individual  sections  of  this  work  and  a  chapter  or  two  following 
will  contain  cross-case  comparisons  and  analysis.  The  analysis  was  done  using  Microsoft  Excel  and  its 
Statistics  Add-in.  Additional  statistical  support  was  provided  by  a  demo  version  of  Vizlon,  and  a  demo 
version  of  Analyse-It,  both  Excel  software  add-ins. 
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CHAPTER  5  -  THE  US  AIR  FORCE  FRONT-END 
PROCESS  CASE  STUDY 


The  US  Air  Force  has  a  decentrali2ed  process  for  its  front-end.  Nevertheless,  it  remains  a  formalized 
process.  This  case  stucfy  will  reflect  both  of  these  observations.  It  is  also  important  to  note  that 
during  the  period  of  observation,  major  changes  to  the  front-end  processes  were  being  contemplated. 
A  team  has  been  working  beginning  April  1999  to  ‘reengineer  the  Requirements  Process’  for  the  Air 
Force. 

The  DoD  view  of  the  Requirements  Generation  System  was  presented  in  Chapter  2.  The  Air  Force 
has  split  this  process  into  two  systems,  the  Modernization  Planning  Process  (MPP)  and  the 
Requirements  Generation  System  (RGS).  The  MPP  controls  the  Mission  Area  Analysis  and  the 
Mission  Need  Analysis  portions  as  a  part  of  the  Air  Force  Planning  process  within  the  Planning, 
Programming  and  Budgeting  System  (PPBS).  The  RGS  contains  the  rest  of  the  process.  The 
Acquisition  System^*  exerts  primary  control  over  the  product  development  process  when  the 
Milestone  Decision  Authority  (MDA)  makes  a  decision  (Milestone  I)  about  the  product  when  an 
Operational  Requirements  Document  (ORD)  is  validated  and  approved  and  also  the  required  funding 
is  in  place. 

The  following  diagram  illustrates  the  overall  information  flow  of  the  Air  Force’s  front-end.  An 
Operational  Requirements  Document  (ORD)  repeats  the  process  beginning  with  the  Requirements 
Organization. 


28  See  Appendix  F  for  more  information  about  the  specific  nuances  of  the  Air  Force  application  of  the  PPBS. 
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Figure  19.  Notional  view  of  AF  Process  flow 


In  the  Air  Force,  each  MAJCOh/P^  owns  and  executes  the  ModemiTation  Planning  Process.  The 
process  reHes  heavily  upon  the  output  of  the  national  strategic  planning  process  for  guidance.  The 
MPP  has  a  cycle  time  of  two  years  -  from  the  be^nning  of  the  process  until  every  step  has  been 
completed.  The  Air  Force  introduced  the  MPP  in  1996  as  an  Air  Force  Process  to  make  the  ‘fuzzy 
front  end’  of  acquisition  more  definitive  and  correa  some  of  the  deficiencies  of  the  previous  front-end 
system  (Weishoff  1990).  See  Appendix  H  for  more  information  about  the  previous  system.  Air 
Combat  Command  has  been  using  a  MPP-like’  process  since  about  1993.  It  was  institutionalized  in 
the  Air  Force  by  1996.  The  process  incorporates  the  use  of  the  ‘Strategy-to-Task’ methodology.  The 
actual  form  of  how  the  Air  Force  has  implemented  this  methodology  exists  in  the  Modernization 
Planning  Process  (MPP)  Flow.  One  of  the  unique  features  about  the  MPP  is  the  extensive 

25  An  organiational  stmcture  in  the  Air  Force  organized  around  specific  mission  tasks  (e.g.  Air  Combat  Command,  Air  Mobility 
Command,  Space  Command,  etc.). 
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participation  of  the  Acquisition  System  in  this  portion  of  the  front-end.  This  kind  of  participation  will 
not  occur  again  until  near  the  end  of  the  front-end  process.  This  diagram  depicts  the  Air  Force  MPP 
flow. 


(Stewart 


1996)^° 


Figure  20.  Modernization  Planning  Process  Overview 


Mission  Area  Teams  (MATs)  and  Technical  Planning  Integrated  Produrt  Teams  (^IPTs)  are  the 
individuals  that  put  the  MPP  into  praaice.  They  are  responsible  for  the  products  of  the  MPP  that  lead 
to  recommendations  for  the  MAJCOM  Program  Objective  Memorandum  (POM)  as  well  as  the 
Science  &  Technology  POM.  They  are  charged  to  develop  non-materiel  and  materiel  solutions  for 
known  needs,  deficiencies,  and  capability  shortfalls.  The  MATs  are  made  up  of  experts  at  the  Action 
Officer  level.  A  Colonel  in  the  Planning  office  at  the  MAJCOM  leads  the  teams.  By  definition,  these 
teams  are  ‘warfighter’-led  with  acquisition  community  participation.  There  are  currently  16  MATs^* 


30  This  reference  gives  the  official  US  Air  Force  guidance  on  the  MPP  (USAF 1996). 

31  The  AF  Mission  Areas  are:  Airlift;  Specialized  Mobdity;  Air  Refueling;  Information  Protection;  Psychological  Operations;  Counter 
Information;  Surveillance  &  Reconnaissance;  Space  Force  Enhancement;  Theater  Battle  Management;  Training  &  Education; 
Aerospace  Control;  Space  Control;  Space  Support;  Strategic  Attack,  Interdiction,  Combat  Air  Support;  Space  Force  Application;  and 
Special  Force  Application. 
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and  a  corresponding  number  of  TPIPTs^^  across  the  entire  Air  Force.  (These  are  not  completely 
aligned  one  for  one  and  an  effort  is  underway  to  align  these.) 

The  MATs  begin  by  conductiag  a  Mission  Area  Assessment  to  determine  the  needs  in  that  team’s 
mission  area  using  the  previously  mentioned  Strategy  to  Task  methodology.  Once  the  needs  are 
known,  the  MATs  conduct  a  Mission  Needs  Analysis  to  define  the  existing  state  of  capability  of  the 
US  Air  Force  in  that  mission  area  and  identify  deficiencies  in  capabilities  required  to  fulfill  those  needs. 
The  next  step  is  Mission  Solution  Analysis.  Its  purpose  is  to  find  potential  solutions,  both  materiel 
and  non-materiel,  that  will  fulfill  the  need.  The  outcome  of  this  stage  is  presented  in  the  Mission  Area 
Plan  (MAP).  The  MAP  contains  the  documented  progress  and  outcomes  of  the  MPP  for  that 
particular  mission  area.  Of  most  importance  are  the  proposed  solution  concepts,  including  tentative 
resource  requirements  (such  as  cost  and  schedule)  for  those  potential  solutions,  both  materiel  and 
non-materiel. 

The  proposed  solutions  are  generated  during  Mission  Solution  Analysis.  Although  the  MAT  oversees 
MSA,  most  of  the  work  is  done  by  a  TPIPT  from  Air  Force  Materiel  Command  (the  Acquisition 
Community).  TPIPTs  provide  analytical,  system  engineering  and  acquisition-related  support  to  the 
user  during  all  phases  of  Modernization  Planning  (Siewers  1997).  The  purpose  of  the  TPIPT  is  to 
provide  unbiased  recommendations  for  materiel  solutions  to  needs  identified  by  the  MATs.  A 
designated  chief  who  is  assigned  a  core  team  of  full-time  personnel  leads  the  TPIPT.  In  addition  to 
the  core  team  members,  the  TPIPT  is  comprised  of  personnel  from  many  organizations  and 
functional  backgrounds,  including  System  Program  Offices”  (SPOs),  Air  Force  and  national 
laboratories,  industry,  warfighters,  and  planners.  The  TPIPT  Chief  is  also  a  member  of  the 
corresponding  MAT  who  supports  the  MAT  during  the  entire  MPP,  with  particular  emphasis  on  the 
MSA  (Siewers  1997). 


32  The  names  of  these  TPIPTs  as  of  4  Aug  98  are:  Air  Superiority,  Air  to  Surface;  Aircrew  Training;  Mobility  Special  Operations  Forces 
(SOF);  Agile  Qjmbat  Support  (ACS);  Command  &  Control;  Intelligence,  Surveillance  &  Reconnaissance  (ISR);  Weather,  Information 
Operations;  Environment,  Safety  and  Occupational  Health  (ESOH);  Education  and  Training;  Crew  Systems;  Space  Control  &  Space 
Eorce  Application;  Space  Eorce  Enhancement;  and  Space  Support. 

33  The  System  Program  Office  is  where  the  development  and  acquisition  of  systems  is  conducted  and/ or  managed.  A  SPO  exists  only 
when  a  weapon  system  has  entered  full  development. 
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As  soon  as  needs  begin  to  be  identified  during  the  Mission  Needs  Analysis,  the  TPIPT  is  already  at 
work  preparing  ‘Concept  CaUs^'*’  to  determine  ways  to  fill  those  needs.  The  Concept  Calls  are  sent  to 
those  in  industry,  Air  Force  and  national  laboratories,  and  the  public  that  demonstrate  an  interest  in 
working  on  a  potential  solution  to  a  need.  This  activity  includes  interfacing  with  concept  developers  to 
help  mature  potential  solutions.  As  solutions  from  the  Concept  Calls  are  evaluated,  the  TPIPT  works 
at  assessing  the  technology  of  the  solution,  identifying  technology  needs  and  development  programs  to 
support  potential  solutions.  These  are  documented  in  the  Technology  Action  Plan  (TAP).  By¬ 
products  of  the  effort  to  identify  mature  technologies  are  TPIPT  recommendations  for  transitioning 
these  technologies  to  existing  programs  and  SPOs.  The  TPIPT  works  on  developing  programs  to 
facilitate  prototyping  and  the  demonstration  of  advanced  concepts  as  well  as  interacting  with  other 
TPIPTs  to  identify  common  solutions. 

Specifically,  TPIPTs  do  the  following  things  during  Mission  Solution  Analysis.  The  TPIPT  conducts 
concept  identification  and  assessment  for  its  particular  mission  area.  (QFD  is  most  often  used  by 
TPIPTs  in  their  assessment  activities.)  The  TPIPT  will  identify,  consolidate  and  analyze  materiel 
solutions  to  identified  deficiencies  and  needs,  and  also  document  detailed  descriptions  of  the  concepts, 
analytical  methodologies,  results,  and  associated  concept  development  roadmaps  and  technology  needs 
in  the  Developmental  Plan^^  (DP)-  The  DPs  are  linked  to  the  appropriate  MAPs,  Technology  Action 
Plans  (TAPs),  and  existing  Weapon  System  Master  Plans^^  to  identify  the  critical  technology  needs. 
The  TAP  provides  a  framework  to  be  used  by  laboratories  and  industry  to  identify  and  assess  various 
concept  technologies.  Additionally,  the  TPIPT  will  identify  appropriate  technology  projects  and 
demonstrations  to  assess  these  technologies  (Siewers  1997). 

After  all  of  the  potential  solutions  have  been  evaluated  (which  is  a  form  of  prioritization),  the  MAT 
determines  which  of  the  solutions  will  be  documented  in  the  MAP.  The  relationship  between  the 
MAT  and  the  TPIPT  is  not  simple  nor  can  be  described  in  a  serial  kind  of  relationship.  The  MATs 


S'*  A  Concept  Call  is  a  formal  request  or  solicitation  by  the  Air  Force,  usually  printed  in  the  Commerce  Business  Daily,  for  industry  to 
present  potential  solutions  in  a  given  mission  area.  The  CaU  contains  all  pertinent  instmctions  about  the  content  format,  the 
presentation  style,  and  also  the  protections  in  place  for  company  proprietary  information.  Most  concept  calls  have  no  funding 
associated  with  them  -  so  any  participation  by  industry  is  voluntary  and  without  remuneration.  Most  companies  view  these  calls  as 
essential  marketing  opportunities  -  in  a  few  years  their  company’s  concept  could  be  the  next  big  purchase  by  the  Air  Force. 

35  Development  Plan  -  A  product  of  the  TPIPT.  It  contains  the  results  of  all  of  the  detailed  solution  analysis. 

35  These  are  plans  regarding  the  future  development  and  modernization  of  existing  weapon  systems. 
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and  TPIPTs  are  always  in  some  phase  of  action  to  support  one  part  or  another  of  the  MPP.  In  some 
respects,  the  MAT  provides  the  broad  focus  for  the  MPP  and  the  TPIPT  provides  depth  to  the 
process  in  the  form  of  detailed  analysis. 


Mission  Area  Teams 


Stewart  1996,  pg-10) 


Figure  21.  Relationship  of  Technical  Planning  Integrated  Product  Teams 
(TPIPT)  to  the  Mission  Area  Teams  (MAT)  of  the 
Modernization  Planning  Process 


Although  the  programming  and  budgeting  portions  of  the  PPBS  rely  upon  the  planning  function  for 
input,  the  Requirements  Generation  System  of  the  Air  Force  is  first  required  to  validate  and  approve 
new  ‘requirements’  that  will  go  into  programming  and  budgeting.  This  requirement  is  one  of  the 
checks  and  balances  in  the  system.  In  order  for  an  item  to  be  programmed  or  receive  money  in  the 
budget,  the  requisite  MNS  or  ORD  must  be  approved  by  the  RGS,  otherwise  the  money  cannot  be 
allocated  and  is  usua%  redireaed.  Nevertheless,  programming  and  budgeting  events  take  place 
outside  of  the  overall  Requirements  Generation  System  and  will  not  be  discussed  here.  This  process 
within  the  Air  Force  is  outlined  in  Appendix  D.  It  is  equally  important  to  remember  that  there  is 
typically  a  two-year  lag  between  programming  some  item  into  the  POM  and  getting  the  money  to 
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spend  during  any  fiscal  year.  The  MAP,  therefore,  serves  as  the  link  between  the  MPP  and  the  RGS. 
Therefore,  the  Requirements  Process  is  just  one  of  several  systems  working  together,  but  acts  as  a  sort 
of  gate-keeping  function.  The  other  processes  (PPBS  and  Acquisition)  are  unable  to  proceed 
‘officially’  in  development  activities  until  the  Requirements  Process  takes  action  by  approving  and 
validating  either  a  MNS  or  an  ORD. 

AF/XO  is  the  Directorate  of  Operations  at  the  Headquarters  Air  Force.  XO  is  the  process  owner  for 
the  entire  Requirements  Generation  System.  XO’s  responsibilities  are  for  day  to  day  operations  -  in 
essence,  this  directorate  represents  the  end  user  and  the  end  user’s  activities  in  the  Air  Force.  Similar 
organizational  stmctures  exist  at  the  MAJCOM  level  for  Operations.  These  groups  ‘own’  the 
Requirements  Processes  at  the  different  MAJCOMs.  Besides  directing  the  authorship  of  the 
document,  the  Reqtoirements  System  mandates  a  series  of  reviews  to  ensure  the  ‘need’  or  requirement 
is  valid.  The  indicated  schedule  for  processing,  validation  and  approval  for  each  document  is 
contained  in  the  Air  Force  Instruction  (API)  10-601,  which  defines  the  Requirements  Generation 
System  of  the  Air  Force. 

Generally  speaking,  the  document  writer  is  an  Aaion  Officer  (AO)  at  a  MAJCOM  in  the  Operations 
Directorate.  The  AO  is  usually  direaed  to  write  a  Mission  Need  Statement  for  a  particular  issue. 
Typical^,  the  AO  finds  the  most  recently  approved  MNS  or  ORD  and  uses  it  to  be  a  reference  or 
baseline  for  the  document  being  developed.  However,  the  MAP  is  not  necessarily  consulted  in  writing 
a  MNS  (although  it  should  be  according  to  the  directives  governing  the  overall  process).  Often,  the 
AO  is  also  serving  as  a  Program  ManageF^  or  Program  Element  Monitor’®  at  the  MAJCOM.  As  such, 
these  individuals  are  extremely  busy  in  their  current  capacities;  they  do  not  have  the  time  to  consult  a 
MAP  for  deficiencies.  They  often  gather  user  needs  and  requirements  direaly  from  the  users  in  the 
field,  sometimes  holding  Requirements  Working  Groups  according  to  their  particular  job  duties, 
mission  areas  and  users  they  represent.  These  working  groups  also  try  to  prioritize  their  needs 
according  to  their  perception.  No  formal  study  or  methodology  is  used  to  prioritize  these  needs. 


37  The  Program  Manager  represents  the  user  in  the  day  to  day  interactions  between  the  end  user  and  the  Acquisition  Program  Manager  of 
a  given  weapon  system. 

38  A  Program  Element  Monitor  (PEM)  is  responsible  for  monitorii^  the  fimding  in  a  given  ‘element’  or  system  classification  according  to 
the  PPBS.  Typically,  the  PEM  has  oversight  responsibility  over  several  similar  programs  (i.e.  all  tanker  aircraft),  and  ensures  that  the 
different  kinds  of  funding  are  properly  spent  and  that  funding  deadlines  are  met.  (Not  all  money  is  the  same  in  a  program  -  some  kinds 
of  money  must  be  spent  within  one  year  of  receiving  it,  other  types  have  up  to  five  years  to  spend  it.) 
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These  needs  are  also  usually  expressed  in  the  format  of  a  specific  solution.  With  this  information,  the 
AO  searches  for  existing  ways  to  deliver  (fund)  the  solution.  If  modifying  a  given  program  can  fulfill 
the  need,  and  the  modification  costs  do  not  exceed  the  cost  thresholds  outlined  by  the  Requirements 
Guidance  (see  Appendix  I),  money  will  be  sought  from  that  source.  Otherwise,  the  AO  searches  for 
an  approved  MNS  or  ORD  that  already  addresses  the  need.  If  no  MNS  is  found,  the  AO  will  begin  to 
draft  a  Mission  Need  Statement.  (If  a  MNS  has  been  found  that  addresses  the  situation,  but  is  not  in 
development  due  to  a  lack  of  funds,  finding  resources  to  pursue  the  development  of  that  MNS 
becomes  the  primaiy  driver.  The  AO  m^  also  begin  to  write  a  draft  ORD  in  parallel  to  finding 
resources  to  expedite  the  process.)  After  the  document  has  been  drafted,  it  must  be  coordinated 
though  the  staff  of  the  MAJCOM  and  then  comments  must  be  resolved.  This  is  actually  one  of  the 
primary  filters  for  ideas.  If  all  of  the  different  organizations^^  at  the  MAJCOM  do  not  ‘buy  into’  the 
idea,  the  effort  essentially  dies.  In  cases  such  as  this,  the  AO  may  initiate  briefings  with  many  of  the 
organizations  to  demonstrate  the  importance  of  the  issue  and  put  new  life  into  the  effort.  Assuming 
all  comments  are  resolved  and  the  MAJCOM  Commander  approves  the  document,  the  MAJCOM  will 
release  the  document  to  the  Headquarters  Air  Force. 

The  staffing  and  schedule  beyond  the  MAJCOM  includes  four  phases  and  five  milestones.  The  first 
milestone  occurs  when  the  MAJCOM  submits  the  draft  document  to  the  Headquarters  Air  Force  at 
the  Pentagon.  The  document  is  given  45  days  of  review  at  the  0-6  level  (Colonel-level)  in  various 
organizations  throughout  the  Headquarters  Air  Force.  These  organizations  are  typically  known  as 
Three-Letter  organizations.  Those  reviewers  in  these  organizations  act  as  a  ‘first-look’  for  the 
document  before  their  boss,  (the  two-letter),  gets  a  chance  to  review  it  later  in  the  overall  process. 
When  this  first  review  is  complete,  the  MAJCOM  receives  the  comments.  The  MAJCOM  then  has  45 
days  to  resolve  all  of  the  comments.  The  MAJCOM  will  then  submit  the  ‘final’  document.  The 
document  is  then  sent  back  through  the  same  staffing  and  reviewing  procedure,  with  a  30-day  time 
limit.  After  the  same  three-letter  organizations  review  and  make  comments  to  the  final  document  (and 
after  those  comments  are  resolved),  the  document  goes  before  the  Air  Force  Requirements  Oversight 
Council  (AFROC)  for  three-letter  coordination  and  recommendation,  (‘endorsement’),  to  proceed 
further  in  the  process  (USAF/DXOR  1999).  At  this  point  the  document  enters  a  final  review  done  by 
general  officers  (the  two-letters).  There  is  no  time  limit  on  this  phase,  and  all  comments  must  be 


Organizations  that  might  be  impacted  such  as  Plans,  Personnel,  Logistics,  etc.  must  verify  they  can  accommodate  the  new  requirement. 
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resolved  before  the  document  moves  forward  in  the  process.  (Typically,  the  two-letters  take  no 
exception  to  the  endorsement  of  the  AFROC.)  When  this  review  is  complete,  the  document  is  sent 
back  to  the  MAJCOM  for  the  Commander’s  signature.  At  this  point,  the  document  is  signed  by  XOR 
and  sent  to  the  XO  (two-letter)  whose  signature  constitutes  ‘validation’  of  the  document.  Once 
‘validated’,  the  document  is  sent  to  the  Chief  of  Staff  of  the  Air  Force  (CSAF)  for  a  signature.  The 
document  is  then  ‘Approved’.  (Rarely,  if  ever,  has  the  CSAF  failed  to  sign  a  ‘validated’  document.) 


Note:  the  validation  authority  changes  according  to  the  ACAT  level.  Accordingly,  ACAT I  documents 
are  ‘recommended’  by  the  XO  to  the  CSAF  for  approval  to  proceed  into  the  Joint  validation  and 
approval  process.  When  the  CSAF  ‘approves’  the  document,  it  enters  the  Joint  Staff  review,  validation 
and  approval  process.  The  document  remains  at  the  Joint  Staff  until  all  comments  have  been  resolved 
and  the  document  is  approved  by  the  JROO®.  ACAT  II  documents  are  validated  by  the  XO.  ACAT 
III  documents  are  validated  by  the  XOR  based  on  the  recommendation  of  the  AFROC.  The  CSAF, 
however,  approves  all  documents.  For  more  information  about  the  actual  process  flow  for  document 
validation  and  approval,  see  Appendix  J. 

The  XORPD  Web  site,  http:/ / www.afreqs.hq.af.mil,  (a  .mil  restricted  web  site),  as  of  December  30, 
1999,  has  a  briefing  entitled  “The  Life  of  a  Document”  that  illustrates  the  process  in  graphical  detail. 
This  process  is  followed  for  each  document  for  a  given  system  (i.e.  both  for  a  MNS  and  an  ORD).'^^ 
Rarely  does  this  process  meet  the  mandated  time  frames. 


Once  a  MNS  has  been  approved  (the  PPBS  has  the  funding  in  place  and  the  Acquisition  System 
makes  its  Milestone  0  Decision),  the  MAJCOM  proceeds  with  an  Analysis  of  Alternatives.  This  is  a 
formal  study  that  seeks  to  evaluate  all  potential  alternatives  to  the  preferred  solution  to  the  need 
indicated  in  the  Mission  Need  Statement.  The  MAJCOM  Studies  and  Analysis  group  either  conducts 
these  studies  or  it  is  awarded  to  a  contractor.  Depending  upon  the  complexity  of  the  contemplated 
system,  the  AoA  usually  takes  between  six  months  and  eighteen  months  to  complete.  The  final 
produa  of  the  AoA  is  a  recommendation  for  a  solution.  Included  with  this  recommendation  are 


Suggested  time  frames  for  the  joint  process  are  found  in  the  regulation  governing  the  joint  requirements  process  (CJCS  1999). 

In  the  fall  of  1999,  a  change  was  made  to  AFI 10-601  deleting  the  need  for  a  MNS  for  potential  Acquisition  Category  (ACAT)  II  or  III 
programs,  so  long  as  a  produa  of  the  MPP  had  validated  the  mission  need.  The  AFRCXD  would  generate  an  AFROC  Staffing 
Memorandum  (AFROCSM)  recommending  validation  and  approval  of  the  mission  need  to  the  appropriate  authority.  Furthermore, 
the  two  cycles  of  review  at  the  Pentagon  were  reduced  to  just  to  one  round  for  all  documents  (USAF/DXOR  1999).  Review 
(tJSAF/DXOR  1999)  for  information  about  Requirements  and  ACAT  levels. 
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certain  key  performance  parameters  that  are  required  for  the  system  to  meet.  Additionally,  trade  space 
on  other  requirements  is  identified  in  the  form  of  threshold  and  objective  requirements. 

To  help  with  the  quality  of  AoAs,  the  Air  Force  established  an  Office  of  Aerospace  Studies  (OAS)  that 
acts  as  an  independent  consultant  to  a  MAJCOM  about  conducting  AoAs.  This  office  has  no 
authority  over  the  AoA,  nor  can  it  pass  judgement  on  the  quality  of  the  AoA.  OAS  does  not  even 
have  to  be  involved  if  the  MAJCOM  chooses  to  exclude  them. 

The  Air  Force  has  approximately  1000  individuals  that  are  engaged  in  Requirements  development. 
There  are  approximately  100  Requirements  documents  that  are  approved  each  year.  About  two-thirds 
of  them  are  Mission  Need  Statements  and  the  remaining  third  are  Operational  Requirement 
Documents.  Regardless  of  the  processes  used  at  the  Major  Commands,  the  overall  cycle  time  for 
these  documents,  whether  a  Mission  Need  Statement  or  an  Operational  Requirement  Document  was 
430  days.  However,  some  documents  have  gone  through  the  system  in  as  few  as  90  days  (particularly 
if  they  have  ‘high-leadership  interest’),  as  well  as  some  documents  that  have  required  well  over  700 
days  to  complete  the  process.  If  analyzed  in  a  serial  fashion,  the  overall  cycle  time  from  the  writing  of 
the  Mission  Need  Statement  until  an  Operational  Requirement  Document  is  written  and  approved 
(including  an  average  Analysis  of  Alternatives  (AoA)  time  of  18  months)  is  approximately  4  years, 
(with  variations  from  1  to  10  years).  This  also  assumes  the  processes  are  in-sync  with  the 
programming  phase  of  the  PPBS  and  that  the  money  required  for  an  AoA  (and  program  start  at 
Milestone  I)  is  immediately  programmed  correaly.  If  all  of  these  items  are  done  correctly,  only  an 
additional  two  years  are  added.  This  also  assumes  that  the  required  political  forces  are  in  place  to  allow 
the  effort  through  the  entire  front-end  process.  Finally,  the  MPP  at  the  beginning  of  the  process 
requires  approximately  2  years  to  indicate  a  need  exists  before  a  MNS  is  written  (USAF/DXOR  1999). 
Therefore,  the  overall  cycle  time  of  the  entire  front-end''^  (executed  in  an  ideal  fashion  as  the  current 
system  is  designed)  is  about  eight  years,  (with  variations  from  3  to  15  years). 

Furthermore,  a  great  deal  of  variation  exists  among  the  MAJCOMs  of  the  Air  Force  concerning  the 
degree  of  adherence  to  the  guidelines  of  the  Modernization  Planning  Process  and  Requirements 
Process.  This  information  is  presented  in  the  table  below.  ‘Existence’  of  the  process  is  defined  by 
functional  departments  within  organizations  tasked  to  accomplish  the  requirements  of  the  process. 

For  another  view  of  the  entire  front-end  process,  please  see  Appendix  K, 
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Maturity’  is  defined  by  the  MAJCOM  taking  steps  beyond  those  found  in  the  official  guidance  to 
improve  the  relationships  and/or  interfaces  between  the  Modernization  Planning  Process,  the 
Requirements  Generation  System,  and  the  financial  aspects  of  the  Planning,  Programming,  and 
Budgeting  System''h 


Table  15.  MAJCOM  Process  Maturity 


Process  Maturity 

MAJGOM 

B 

B 

B 

B 

B 

B 

Modernization  Planning  Process  exists 

B 

X 

B 

B 

Modernization  Planning  Process  is  mature 

B 

B 

Requirements  Generation  System  exists 

B 

B 

B 

B 

B 

X 

Requirements  Generation  System  is  mature 

X 

X 

Planning,  Programming,  Budgeting  System  exists 

X 

X 

X 

X 

X 

X 

PPBS  is  mature  (Fiscal  constraining  of  MPP  for  FYDP) 

X 

X 

Despite  the  noted  differences,  the  average  process  times  (in  the  case  of  document  development, 
validation,  and  approval)  displayed  no  notable  differences'*'*  between  the  ‘mature’  processes  and  those 
that  were  not.  There  also  are  no  measures  available  or  recorded  relative  to  the  overall  process  yield 
(i.e.  how  many  needs  identified  in  the  MPP  actually  are  funded  and  get  to  program  launch  or 
Milestone  I).  One  MAJCOM  provided  the  following  information  on  the  partial  process  yield  for  the 
PT02  POM:  of  the  646  needs  (with  a  conceptual  solution  identified  through  the  MPP)  only  29  or 
4.4%  of  them  were  placed  into  the  MAJCOM  POM.  Of  that  number,  zero  survived  into  the  Air 
Force  POM.  It  was  not  known  how  many  of  these  needs  were  simultaneously  being  prepared  by  the 
Requirements  Generation  System.  As  one  interviewee  noted,  “These  things  change  hands  so  often, 
you  never  know  what  happens  to  them.” 

Organizational  Issues 

The  Air  Force  front-end  contains  many  duplicative  functions  between  the  headquarters  and  the 
MAJCOMs.  The  duplication  is  not  so  much  an  issue  as  between  MAJCOMs  with  legitimately 

“*3  The  ties  to  the  Acquisition  system  were  not  addressed  because  they  do  not  become  actively  involved  in  the  process  until  after  the  MNS 
is  validated. 

The  quality  of  the  Requirements  Document  could  not  be  measured  -  it  was  deemed  too  subjective  &  diffiailt  to  quantify.  However, 
anecdotal  evidence  delivered  orally  by  various  interviewees  indicates  quality  is  a  factor.  For  instance,  many  documents  are  written  in 
the  language  of  the  operating  environment  (e.g.  space)  and  are  not  written  to  be  read  or  understood  by  the  entire  Air  Force  - 
particularly  important  during  a  document’s  coordination  and  validation  phases. 
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different  missions;  rather  it  is  between  the  duplication  of  effort  between  all  of  the  MAJCOMs  and  the 
headquarters  (each  has  Modernization  Planning,  Requirements,  and  PPBS  functions).  Each 
organizational  group  has  an  organization  dedicated  to  the  PPBS  (and  the  MPP  within  the  PPBS)  and 
the  Requirements  Process.  There  does  not  appear  to  be  any  integrative  structure  within  the  process 
outlined.  The  only  integrative  effort  similar  to  a  business  case  decision  that  occurs  is  during  the  Air 
Force  Group  review  in  the  PPBS  stmcture  (see  Appendix  D). 

There  are  multiple  reviews  and  screens  within  the  process.  The  process  is  designed  with  these  in 
mind,  but  it  is  not  clear  what  the  value  added  to  the  document  is,  except  that  anyone  who  wants  to 
know  what  is  going  on,  is  able  to. 

TPIPTs  seem  to  be  the  team  that  actually  develops  solutions.  Rather  than  allowing  them  to  continue 
their  efforts  -  and  potentially  build  a  business  case  -  the  concepts  and  responsibility  from  them  are 
taken  out  of  their  hands  and  are  developed  through  the  MAT  and  then  evenmally  through  the  person 
that  actually  decides  to  write  a  Mission  Need  Statement.  It  would  appear  the  TPIPTs  represent  the 
technological  professionals  and  the  MATs  and  Requirement  document  originators  are  simply  end 
users.  Also  unusual  is  the  current  cool  reception  TPIPTs  are  now  receiving.  AFMC  has  not  placed 
much  emphasis  on  them.  In  fact,  there  are  some  TPIPTs  that  exist  in  name  only  because  there  are  not 
enough  personnel  and  resources  to  function  in  TPIPT  positions.  Funding  for  these  TPIPTs  also 
seems  to  be  a  point  of  contention.  The  MAJCOMs  do  not  want  to  provide  resources,  and  AFMC 
does  not  either.  The  specific  funding  element  in  the  Air  Force  for  pre-Milestone  0  studies,  PE65808, 
has  virtually  no  funding  at  all.  Interviewees,  particularly  those  who  write  MNS  and  ORDs,  expressed 
many  comments  that  TPIPTs  exist  to  only  follow  the  whims  and  desires  of  the  ‘pocket-protector’ 
wearing  acquisition  personnel  and  that  they  provide  no  real  value.  However,  people  within  the 
Planning  community  did  not  echo  these  sentiments.  They  are  dependent  upon  the  TPIPT  for  inputs 
to  the  MPP.  These  perceptions  highlight  disconnects  between  the  Modernization  Planning  Process 
and  the  Requirements  Generation  System. 

The  Air  Force  MAJCOMs  interpret  governing  guidance  and  regulations  differently  and  therefore, 
some  MAJCOMs  have  a  very  formalized  MPP,  while  others  have  none  at  all.  The  same  is  tme  for  the 
staffing  guidelines  in  RGS  as  well. 
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Upon  completion  of  the  AoA,  an  AoA  Report  is  published.  This  report  serves  as  the  primary  input  to 
the  Operational  Requirements  Document  (ORD).  While  the  AoA  is  stiU  in  progress,  it  is  typical  for  a 
draft  ORD  to  already  exist  and  as  more  results  are  known  from  the  AoA,  the  draft  ORD  is  updated. 
This  is  partially  done  to  eliminate  delay  time  from  the  completion  of  the  AoA  to  the  approval  of  the 
ORD.  Unfortunately,  some  ORDs  have  been  through  the  entire  review  and  validation  process 
(identical  to  the  process  used  for  a  MNS)  before  the  AoA  is  completed  or  the  ink  is  dry  on  the  AoA 
Final  Report.  Additionally,  pressures  of  time  (to  reduce  the  amount  of  time  required  to  begin  a 
system’s  development)  and  other  resource  constraints  (no  money  programmed  or  not  enough  time  to 
get  money  for  an  AoA  programmed)  have  led  to  the  proliferation  of  AoA-like’  studies.  Bluntly  put, 
these  are  quick  efforts  that  do  not  go  into  the  depth  of  analysis  and  detail  that  an  AoA  would.  The 
quality  of  these  studies  is  likely  to  be  equally  diminished. 

Business  Issues 

There  is  no  formal  business  case  developed  by  the  RGS.  The  closest  thing  to  such  a  business  case 
exists  at  Milestone  I  during  which  very  rough  costs  are  presented,  but  funding  decisions  appear  to  be 
based  solely  upon  total  costs  and  the  ability  to  fit  a  program  within  the  current  fiscal  environment. 
Furthermore,  individuals  who  do  not  participate  in  the  Requirements  Process  and  have  little  insight 
into  the  Requirements  Process  make  these  funding  decisions. 

The  Air  Force  has  multiple  databases  and  IT  capabilities,  but  they  are  not  integrated.  About  the  only 
thing  standardized  within  the  Air  Force  are  email  address  naming  conventions  and  using  the  Microsoft 
Office  Suite  produas. 

The  Air  Force  does  not  consider  the  costs  associated  with  the  existence  of  the  front-end  system, 
whether  iti  terms  of  personnel  costs,  nor  in  terms  of  the  opportunity  costs  (e.g.  requirements  that 
become  dated  and  are  no  longer  as  valid  or  correct). 

Modifications  to  existing  systems  are  also  covered  by  regulation.  Since  the  relative  number  of  new 
programs  is  dwindling  (lack  of  money,  etc.),  the  pressure  to  modify  existing  programs  and  systems  has 
only  grown.  These  modifications  also  consist  of  requirements  and  are  handled  by  the  Requirements 
System  as  well.  However,  because  these  programs  already  have  funding  secured,  the  time  between  a 
Requirement  Document’s  preparation  and  the  execution  of  the  requirement  is  much  shorter  than 
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using  the  process  for  a  ‘new’  requirement.  Most  MNSs  and  ORDs  today  have  been  developed  this 
way  (and  contrive  links  back  to  a  MAP).  This  seems  to  be  the  preferred  method  of  requirements 
generation  in  the  Air  Force.  Again,  this  highlights  the  differences  between  the  Modernization 
Planning  Process  and  the  Requirements  Generation  System.  These  differences  also  tend  to 
strengthen  the  relationships  between  the  TPIPT  and  existing  SPOs. 

Summary 

Clearly  the  Air  Force  has  a  formal  process.  However,  it  is  disjointed  and  the  processes  do  not  seem  to 
support  one  another.  A  team  rarely  develops  requirements;  rather  it  is  an  individual  tasked  by  the 
organization  to  write  them  down.  They  are  corrected,  modified,  and  clarified  by  means  of  the 
exhaustive  review  and  approval  process. 


Front-End  Process  Flow 


Identification 


Initial 

Screening 


Concept 

Development 


Business  Case 
Development 
/  Final  Screen 


Figure  22.  Air  Force  Front-end  Process  in  Terms  of  the  Framework 


The  process  diagram  highlights  the  major  process  disconnect  between  the  actual  MPP  and  the 
‘Requirements  Process.’  A  closer  look  at  the  process  in  terms  of  screens  and  approval  forums  reveals 
there  are  3  formal  screening  functions  and  two  approval  fomms  within  the  Air  Force  alone.  The 
overall  process  including  the  joint  process  has  a  total  of  5  screening  processes  and  two  approval 
forums.  Both  Mission  Need  Statements  and  Operational  Requirement  Documents  foUow  this 
process. 

The  process  accepts  multiple  input  from  various  locations.  Interestingly  enough,  most  of  the  inputs  to 
the  ideal  Modernization  Planning  Process  (MPP)  are  also  very  active  at  the  Requirements 
Organization.  This  representation  is  actually  an  oversimplification.  Most  of  these  inputs  are  being 
made  in  a  variety  of  areas,  from  convincing  the  end  user  concerning  a  potential  product  to  invited 
presentations  at  the  MAJCOM  Headquarters.  If  the  user,  for  example,  can  convince  the  Requirements 
community  of  the  vahdity  of  the  need,  the  Requirements  community  will  exert  pressure  on  the 
Modernization  Planning  Process  to  ‘identify’  the  need.  Also,  opportunities  to  circumvent  the  process 
exists  when  the  Requirements  Community  uses  wide  latitude  in  correlating  an  identified  need  with  the 
‘requirement’  in  the  process  of  being  validated.  The  governing  instructions  and  regulations  for  the 
Requirements  process  allow  multiple  MNS  and  or  multiple  identified  needs  within  a  Mission  Area  Plan 
(MAP)  to  be  the  basis  for  an  ORD. 

The  process  requires  at  least  8  years  to  get  through  in  a  serial  fashion  and  there  is  a  great  deal  of 
pressure  to  use  other  methods  to  circumvent  the  process.  Concurrent  Engineering  is  the  term  used  by 
the  Air  Force  to  describe  parallel  activities.  It  is  not  uncommon  to  see  these  things  happening  in  the 
front-end  as  well. 

There  are  alternative  processes  to  the  normal  Requirements  Process,  the  RRP  and  SMART  processes. 
However,  these  are  bound  by  a  certain  set  of  restriaions.  The  RRP  process  must  have  an 
overwhelming  requirement  that  demands  immediate  attention.  This  really  occurs  only  during 
conflicts.  However,  the  RRP  is  the  only  way  that  a  Warfighting  Commander-in-Chief  (CDSfC)  can 
directly  submit  a  requirement  into  the  process;  normally,  these  must  go  through  a  MAJCOM  (as  per 
Federal  law).  The  SMART  process  is  really  only  for  those  systems  that  are  ready  to  go  into  production 
immediately.  Additionally,  these  systems  must  already  have  funding  identified  and  secured  from 
another  source  for  at  least  two  years  until  the  program  can  be  incorporated  into  the  MAJCOM  POM 
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(usually  coming  from  a  MAJCOM’s  discretionary  funding)  (USAF/DXOR  1999).  Finally,  the  last 
groups  of  programs/systems/ideas  that  are  exempt  from  developing  a  MNS  for  the  Requirements 
Process  as  described  are  those  Communications  and  Information  mission  needs  with  a  projected 
program  cost  of  <$15  million.  They  will  use  a  Communications  and  Information  Systems 
Requirements  Document  (CSRD)  as  a  MNS  lAW  AFI  33-103,  Requirements  Development  and 
Processing  (USAF/DXOR  1999). 

In  the  course  of  this  analysis,  this  was  one  subject  that  came  up  that  is  outside  the  scope  of  this  effort 
but  is  worthy  of  mention.  There  is  a  great  deal  of  produa  development  that  occurs  within  the  Air 
Force,  particularly  software  development,  that  falls  under  the  discretionary  funding  of  a  MAJCOM  or 
other  organization  commander.  This  type  of  development  does  not  require  any  kind  of  requirement 
documentation  such  as  a  Mission  Need  Statement  or  Operational  Requirement  Document.  The 
development  of  software  may  be  worthy  of  a  MNS  or  ORD,  but  the  discretionary  funding  regulations 
do  not  require  it.  These  programs  are  governed  by  a  separate  set  of  instructions.  The  form  required  is 
a  Communications-Computer  System  Requirements  Document  (CSRD)  which  is  used  to  identify 
Command,  Control,  Communications,  Computer  and  Intelligence  (C4I)  requirements  less  than 
SSMillion  dollars.  They  are  processed  through  a  separate  system  whose  main  concern  is  ostensibly  on 
system  interoperability  (but  probably  just  operability)  and  not  on  overall  program  necessity. 

Some  of  the  Air  Force  Acquisition  Produa  Centers  (there  are  three  of  them)  have  centers  that  develop 
and  maintain  software.  When  MAJCOM  ‘home-grown’  software  developments  mn  into  trouble,  the 
Produa  Centers  are  petitioned  for  help.  This  results  in  the  creation  of  a  Service  Level  Agreement 
(SLA).  These  SLAs  are  as  large  as  $2  Million  dollars  per  year,  and  are  on  average  about  $1  Million 
dollars  per  year.  None  of  these  come  under  the  scrutiny  of  the  Headquarters  Air  Force.  Individually, 
these  SLAs  are  too  small  to  warrant  any  attention,  but  the  program  size  can  be  deceiving.  Each  SLA 
can  be  renewed  yearly,  as  needed,  to  support  a  given  software  development.  Some  of  these  SLAs  have 
been  going  on  for  years.  These  yearly  agreements  are  considered  ‘new  efforts’  by  the  ‘system’  (the 
PPBS)  and  the  governing  guidance. 

At  one  Produa  Center  alone,  there  are  about  300  aaive  SLAs  and  another  200  more  in  sustainment. 
Both  of  these  types  of  SLAs  deal  with  requirements.  The  aaive  SLAs  are  in  the  development  phase  of 
the  software  application  and  requirements  (i.e.  funaionality)  are  at  the  core  of  the  process.  The 
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sustainment  SLAs  take  care  of  missed  funaionality,  bug  fixes,  and  enhancements  that  also  form  a  type 
of  requirements  management. 

Despite  the  small  size  and  nature  of  these  SLAs,  at  this  product  center  alone,  there  is  more  than  $100 
Million  dollars  per  year  spent  through  these  agreements.  If  they  were  counted  as  ‘one’  program  (i.e. 
Miscellaneous  Software  Development)  with  multi-year  funding,  over  a  five-year  period  it  would  be 
more  than  $500  Million  dollars  -  exceeding  the  threshold  required  to  qualify-  as  a  Major  Defense 
Acquisition  Program  (MDAP)  and  fall  under  the  purview  of  the  Requirements  Generation  System. 

As  an  example  of  the  issue  surrounding  software  development  and  their  requirements,  one 
organization  started  a  program  to  automate  a  common  task.  After  spending  over  $45  Million  dollars 
(via  discretionary  funding  and  over  an  unspecified  amount  of  time),  the  effort  was  in  so  much  trouble, 
a  produa  center  was  asked  to  help.  The  produa  center  recommended  scrapping  the  program  entirely 
because  it  was  so  poorly  architected.  A  SLA  was  made  and  within  a  short  period  of  time  (unspecified, 
but  indicated  as  substantially  less  than  the  first  tiy)  and  for  much  less  money  (again  unspecified),  the 
product  was  delivered  to  the  customer  (MAJCOM). 
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CHAPTER  6  -  ADDITIONAL  CASE  STUDIES 


The  companies  chosen  for  the  other  case  studies  possessed  either  one  of  two  qualities  or  both.  The 
major  quality  was  that  the  companies  chosen  dealt  with  product  development  issues  that  were 
extremely  large,  complex,  and  technologically  advanced,  as  are  most  military,  particularly  US  Air  Force 
product  development  projects.  The  second  quality  was  that  these  companies  have  been  recognized  as 
being  rather  successful  in  their  front-end  processes  by  other  reputable  consulting  firms,  particularly 
those  that  consult  heavily  in  the  product  development  niche. 

Commercial  Companies 

There  are  eight  commercial  companies  presented.  They  include  companies  that  deal  directly  with 
other  manufacturers,  end  users,  and  regular  consumers  (or  any  mix  of  those  three).  Two  companies 
are  primarily  manufacturers  of  product  development  activities  and  deal  only  with  end  users.  Another 
two  companies  primarily  are  purchasers  of  manufacturer’s  products  (i.e.  they  are  end  users  (and  not 
average  consumers)).  Three  companies  are  producers  that  have  an  equal  mix  of  approaches  to  the 
three  kinds  of  customers  listed  above,  and  one  company  is  focused  solely  on  the  front-end  (It  is  the 
product  development  organization  for  a  larger  manufacturing  company.) 

All  of  these  companies  display  analogues  similar  to  existing  military  organizational  relationships. 

Company  A 

Company  A  is  a  large  chemical  applications  company  with  headquarters  in  the  Northeastern  USA.  It 
has  a  formal  Product  Development  Process.  This  process  is  documented  in  a  written  plan.  It  was 
developed  within  the  past  five  years,  taking  the  best  pieces  from  their  different  business  units’  planning 
processes,  (most  of  which  were  recycled  from  a  major  US  Automaker’s  Quality  Plan),  the  parent 
company’s  product  development  process,  and  inputs  from  their  Program  Management  department. 

The  company  cites  two  major  reasons  for  having  this  process:  it  ensures  a  steady  stream  of  products 
(to  include  Speed  to  Market,  Cost,  Quality,  and  Innovation),  and  the  alignment  (alignment  of  Business 
Management,  Program  Management,  and  Tl&D,  Product  Development,  and  Manufacturing 
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Operations’)  it  forces.  Business  Management  leads  produa  development.  Program  Management  is 
viewed  as  an  Enabler  for  the  overall  process.  The  other  processes  add  value  to  the  product. 

The  following  diagram  indicates  Company  A’s  front-end  processes. 


Front-End  Process  Flow  ^ 

Program 


Figure  23.  Company  A's  Front-end  Process'*^ 


The  two-stage  process  (Concept  Approval,  Program  Approval)  depicted  above  adds  stmcture  and 
robustness  to  a  typical  Stage-gate  Produa  Development  Process.  The  specific  aaivities  during  these 
stages  will  be  described  in  the  following  paragraphs. 


Ackpted  from  the  company’s  formal  product  development  process  plan. 
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Overall,  the  company's  New  Product  Development  Process  has  five  phases:  Program  Initiation, 
Research  Evaluation  &  Design,  Product  &  Process  Development,  Product  &  Process  Qualification, 
and  Feedback.  The  process  also  has  three  approval  stages:  Concept  Approval,  Program  Approval,  and 
Product  Launch.  Program  Initiation  correlates  with  the  framework’s  Identification  of  Requirements 
stage.  Research  Evaluation  &  Design  Phase  correlates  with  the  framework’s  Concept  Development 
Phase.  The  Concept  Approval  Stage  correlates  with  the  framework’s  Initial  Screening  Stage.  The 
Program  Approval  Phase  correlates  with  the  framewoik’s  Business  Case  Development  /  Final  Screen 
Stage. 

For  the  purposes  of  this  case  study,  only  the  first  two  stages  will  be  explained  because  those  stages 
encompass  the  area  defined  in  the  idealized  framework  for  the  front-end.  The  other  three  stages  are 
typical  for  a  stage-gate  produa  development  process.  Finally,  the  company  uses  four  Tists.’  These  are 
the  Produa  Proposal  List,  the  Operational  List,  Produa  Launch  List,  and  R&D’s  Technology  List. 
The  term  Tist’  is  more  than  a  list  of  projeas.  It  is  a  name  for  the  matrix  that  describes  the  portfolio 
management  process  of  the  company  and  it  consists  of  the  projea  name,  the  objeaive,  and  the  marka 
timing  required  along  with  schedules  of  defined  aaivities,  etc.  Accompanying  this  information  are 
PowerPoint  style  charts  that  further  describe  the  projea.  This  information  is  stored  on  a  corporate 
information  system  or  an  executive  information  system.  Combining  the  Produa  Proposal  list  and  the 
Produa  Launch  List  essentially  represents  the  company’s  five-year  roadmap. 

The  First  Phase  is  called  Program  Initiation.  There  are  five  sources  of  information  used  in  this  phase: 
OEM/ customer  inputs,  competitor  aaivity,  other  data,  the  strategic  business  plan,  and  new  ideas.  The 
outputs  of  this  step  include  the  following:  an  initial  Screening  Committee  review,  a  Patent  opportunity 
analysis.  Consumer/ OEM/trade  value  analysis,  a  Technology  -  Manufacturing  Opportunity  Screen,  a 
Draft  Program  Plan,  and  a  Feasibility  Study  Request. 

Additional  inputs  come  from  several  sources.  These  range  from  typical  marketing  aaivities:  like 
listening  to  the  customer,  OEM  requirements,  and  unsolicited  ideas  from  any  source  (customers, 
consumers,  and  employees,  etc.).  The  company  will  put  together  a  team  to  do  studies  on  these  ideas. 

t 

More  on  the  team  composition  will  be  addressed  later.  The  company  has  money  set  aside  for  these 
preliminary  analyses  up-front.  The  company  is  flexible  and  variable  in  budgets  for  these  teams  doing 
studies  as  they  realize  that  some  unofficial  work  must  be  done  to  get  a  ‘ballpark’  figure. 
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Advanced  Business  Development  is  a  division  of  the  company  that  deals  not  only  developing  new 
business  through  applying  technology  but  also  with  exploiting  technology  gaps.  It  provides  seed 
money  for  new  R&D  projeas  with  business  potential.  Because  this  company  is  a  platform-based 
company,  technology  gaps  (as  described  by  the  technical  literature)  are  bound  to  exist  in  their  product 
offerings.  When  technology  gaps  are  recogni2ed,  and  it  is  something  the  company  will  not  overcome 
using  internal  resources,  the  company  looks  outside  the  organization.  The  company  is  aggressive  in 
pursuing  ‘garage  shops’,  universities,  other  company’s  technology  through  license  agreements,  etc. 
However,  the  decision  to  pursue  these  opportunities  is  done  according  to  the  direction  of  the 
Screening  Committee. 

The  responsibility  for  the  front-end  rests  with  the  Screening  Committee.  Its  members  are  cross¬ 
functional,  high-level  managers  (VP  of  departments  and/or  divisions).  The  Screening  Committee 
determines  budgets  and  it  also  does  the  ‘Gatekeeping’  funaion.  Members  of  this  committee  are  the 
Vice  Presidents  from  Technology,  Marketing,  Manufacturing,  Program  Management  Group,  R&D 
Operations,  Original  Equipment  Manufacturer  (OEM)  Sales,  and  Advanced  Business  Development. 
The  committee  is  to  lead  the  generation  and  screening  for  innovative  product  ideas  and  technologies 
to  ensure  that  products  and  technologies  are  prepared  to  meet  the  company’s  short  and  long-term 
growth  objectives.  The  committee  generates  and  maintains  a  list  of  promising  produa  and  technology 
ideas  that  generate  a  continuous  stream  of  new  or  improved  produas  allowing  major  product  launches 
at  least  every  two  years.  If  the  committee  is  unable  to  agree  on  an  item,  they  defer  the  decision  to 
higher  management.  When  the  committee  judges  a  concept  is  ready,  it  is  given  to  program 
management.  The  Horizon  committee  also  actively  assembles  feasibilily  study  plans  with  the  help  of 
the  team  that  began  the  initial  investigation  of  the  idea.  There  are  lots  of  different  aaivities  going  on 
at  any  given  time  (in  the  form  of  team  oversight  for  the  different  investigatory  teams)  and  the 
committee  coordinates  all  of  these  activities.  The  Screening  Committee  is  a  small  group  (usually  7 
people)  and  is  able  to  manage  and  control  resource  and  priority  issues.  This  is  the  committee’s 
responsibility.  The  committee  has  direa  access  to  corporate-level  management  (i.e.  the  Presidents  of 
the  different  company  divisions).  The  committee  will  take  tabs  on  what  had  been  done  since  their  last 
meeting.  The  committee  is  also  empowered  to  take  action  if  not  enough  ideas  are  in  the  overall 
development  queue. 
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The  company  uses  teams  to  put  together  programs,  and  these  teams  follow  that  particular  project  until 
it  is  put  into  production  and  sent  to  the  market.  Because  of  the  difficulty  involved,  they  try  to  negate 
the  difficulties  of  the  front-end  by  using  cross-functional  teams  or  promoting  cross-fertilization  of 
teams.  The  committee  believes  “the  more  the  market  is  understood,  the  better  the  technology,  and  the 
more  the  technology  is  understood,  the  more  creative  the  business.”  This  phrase  relates  directly  to  the 
close  relationship  between  the  designers  and  the  marketers.  Team  sizes  may  vary,  as  well  as  in  the 
discipline  and  background  of  the  team's  members,  but  there  will  always  be  one  technical  person  and 
one  marketing  person  on  each  team.  Team  size  will  vary  on  the  low  end  from  2  people  and  on  the 
upper  end  from  7  to  9  people. 

There  is  no  time  limit  set  or  required  for  the  Identification  or  Program  Initiation  Phase.  The  key  to 
this  part  of  the  process  is  having  the  concept  evaluated  by  the  Screening  Committee  during  one  of  its 
regularly  scheduled  meetings.  The  committee  meets  every  6  to  8  weeks,  where  projects  are  evaluated. 
During  the  execution  of  the  company’s  strategic  planning  process,  the  meeting  occurs  every  4  weeks. 

The  Screening  Committee  pushes  during  the  early  stages  of  development  (while  the  idea  is  stlU  in  the 
identification  stage)  for  small  amounts  of  money  to  further  gather  as  much  information  as  possible 
about  an  idea.  The  committee  looks  for  a  draft  business  plan,  called  a  Projea  Brief,  before 
considering  to  start  further  development.  The  brief  should  define  the  fundamental  reasons  why  the 
concept  will  deliver  results  according  to  the  company’s  needs  and  strategic  direction.  The  project  brief 
is  the  interim  documentation  the  company  will  use  to  track  objectives.  It  documents  criteria  in 
sufficient  detail  for  management  to  approve  a  design  project  and  includes  the  following  criteria: 
Primary  Projea  Objeaives  {Design  requirements,  key  strategies,  and  milestones}.  Resource 
Requirements  and  cost  estimates  (Team  members  and  skills,  organizational  and  technical  interfaces,  or 
Special  equipment  and  facilities  needs  during  research  and  development.}  Process  Requirements  for 
the  new  design  including  critical  process  charaaeristics  (if  applicable),  Projea  Target  Completion  Date 
and  the  Exit  Criteria  for  projea  completion.  It  also  addresses  aspeas  of  the  produa’s  Application, 
Contraa  Requirements,  Cosmetics  and  Appearance,  Cost  Estimates,  Environment  issues.  Equipment 
Requirements,  Legal  Requirements,  Marketing  Information  (Competitive  Situation,  volumes. 
Customer  &  OEM  Input,  etc.).  Size  and  Configuration,  Safety  Requirements,  Standardization, 
Regulatory  Requirements,  Quality  Plan  Requirements,  Process  Requirements,  Performance 
Requirements,  and  Manufacturing  Requirements, 
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If  there  is  agreement  by  the  members  of  the  Screening  Committee,  the  project  brief  has  sufficiently 
outlined  the  resources  required,  criteria  for  success,  etc.  When  the  committee  is  satisfied  with  the 
progress  made  on  the  draft  document,  it  is  converted  to  an  approval  document.  This  document  is 
called  a  Program  Initiation  Request  (PIR).  It  combines  the  list  of  project  criteria  defined  within  the 
Project  Brief  with  a  cover  sheet  where  program  approval  signatures  are  maintained.  Issuance  of  the 
PIR  constitutes  Concept  Approval. 

Currently,  in  this  stage  of  the  product  development  process  at  the  Screening  Committee  meetings, 
about  100  new  produa  ideas  get  discussed.  Perhaps  10  of  these  are  approved  and  move  forward  as  a 
PIR,  and  an  additional  10  to  20  are  placed  into  a  low-level  consideration  category  for  further 
investigation.  The  Product  Proposal  List  contains  a  list  of  the  approved  new  product  concepts  and 
also  is  a  matrix  of  the  program  names  and  potential  launch  schedules.  Program  Management 
maintains  the  List  for  the  Screening  Committee. 

Concept  Exploration  or  Research,  Evaluation  &  Design  is  the  next  step  in  the  process.  The  Inputs  to 
this  phase  are  the  previous  phase’s  outputs,  benchmarking  data,  and  market  research.  The  Outputs  of 
this  phase  are  mostly  form  of  information:  information  to  report  the  results  of  the  feasibility  study, 
(product  cost  targets,  timing/schedule,  list  of  special  processes,  list  of  critical  characteristics); 
information  to  specify  the  Product  Specifications,  (design  targets,  quality  targets);  information  to 
develop  a  Detailed  Program  Plan;  information  to  provide  an  Estimated  Program  Cost;  and  a  more 
refined  draft  Business  Plan. 

The  original  team  conducts  a  detailed  analysis  during  this  phase.  The  analysis  is  simply  a  targeted 
understanding  of  how  well  the  product  might  do  given  a  set  of  market  assumptions.  The  Screening 
Committee  will  use  the  analysis  to  look  at  the  implications  of  making  product  development  decisions. 
The  criteria  to  measure  the  implications  come  from  the  strategic  plans  of  the  company.  When  a  new 
idea  is  given  permission  to  enter  concept  development  to  be  investigated,  the  team  wiU  form  a 
hypothesis,  which  it  wiU  try  to  validate  with  consumers,  technical  experts,  and  trade  organizations. 
The  time  taken  for  the  anafysis  varies  according  to  the  complexity  of  the  issue.  Where  there  is  some 
complexity  of  issues,  90  days  is  usual,  but  more  complex  issues  can  take  up  to  6  months  or  more.  The 
team  will  specifically  look  to  see  what  strategic  options  there  are  and  how  the  company  can  take 
advantage  of  them. 
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New  Produa  Ideas  are  always  addressed  from  two  areas  during  this  phase:  a  marketing  point  of  view 
and  also  a  technology  point  of  view.  On  the  marketing  point  of  view,  the  team  tries  to  understand  the 
market,  and  anticipate  what  it  will  demand.  This  takes  the  form  of  a  5-year  look  with  estimated  sales 
and  other  market  data.  According  to  the  company,  it  is  virtually  impossible  to  go  beyond  that  with  any 
degree  of  accuracy. 

On  the  technology  side,  the  most  important  question  asked  is  "What  would  it  take  to  enter  the 
market?"  Again,  because  of  this  focus  on  the  market,  a  Cross-functional  team  has  to  answer  this 
question.  Additionally,  the  team  tries  to  answer  the  question  of  “What  does  the  product  have  to 
deliver  to  the  customer?”  The  team  does  this  beginning  with  using  additional  market  research  and 
pursuing  all  available  sources  of  information.  During  this  time,  the  team  will  come  up  with  alternate 
systems  and  standards.  It  will  pick  one  or  two  of  the  alternatives  as  most  promising  and  then  the  team 
win  pass  the  idea  to  the  technical  people  within  the  organization.  In  this  case,  the  technical  people  are 
technically  grounded  people  that  are  not  part  of  the  core  team,  but  are  highly  respected  for  their 
opinions  and  may  come  up  with  different  options  for  the  new  product.  These  options  can  be  very 
diverse.  They  range  from  differences  in  packaging,  engineering,  chemistry,  and  others.  Furthermore, 
the  core  team  will  try  to  do  even  broader  assessments.  For  instance,  they  will  consider  the  time  for 
development,  the  ‘sweat  equity’  involved,  what  barriers  exist,  etc. 

Another  one  of  the  outputs  of  the  core  team  during  this  phase  is  the  product  plan.  The  product  plan 
has  a  basic  theme  -  communication  to  consumers.  How  much  emphasis  should  be  in  a  certain  area, 
what  the  nature  of  the  new  product  should  be,  what  legal  and  regulatory  requirements  exist  are  all 
elements  of  this  plan.  It  becomes  an  important  part  of  the  PIR. 

Upon  completion  of  this  phase,  the  team  prepares  the  project  for  review  by  the  Senior  Committee. 
Upon  approval,  the  feasibility  study  is  formalized  and  it  is  no  longer  a  draft  document.  The  PIR  is 
approved  and  becomes  the  basis  for  the  new  program.  This  information  is  recorded  on  the  Program 
Launch  List.  This  list  contains  produrts  that  have  been  approved  for  implementation  and  launch, 
additionally  the  list  contains  potential  launch  schedules  for  each  program.  The  newly  approved 
program  then  enters  the  company's  Product  &  Process  Development  phase,  which  is  the  beginning  of 
the  company’s  stage-gate  product  development  process.  Their  cost  thresholds  for  new  products  range 
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from  $300  M  to  $1  Billion.  Anything  more  than  that  becomes  an  issue  for  the  parent  company  to 
handle. 

OygcmTutkml  Issues 

The  company  has  no  formal  training  plan.  It  is  done  on  an  ‘ad  hoc’  basis.  Usually  an  outside 
consultant  is  brought  in  to  work  with  a  specific  team.  The  company  also  feels  that  every  employee  is 
keyed  into  the  same  NPD  issues  that  management  is.  Promoting  company  values,  offering  incentives 
to  develop  new  produas,  and  using  recognition/rewards  programs  does  this. 

Business  Issues 

Additionally,  the  Screening  Committee  mentioned  earlier  oversees  R&D  as  well  as  the  planning 
process.  Separately,  Research  &  Development  does  research  according  to  its  own  agenda.  It  is  not 
necessarily  tied  to  the  strategic  plan  or  vision  of  the  company.  This  strategy  is  done  on  purpose.  R&D 
is  charged  with  the  development  of  new  technologies  and  to  track  new  process  techniques.  Although 
they  are  independent,  the  company  believes  R&D  does  its  work  with  some  sense  of  what  long-term 
issues  are.  For  instance,  R&D  often  uncovers  with  interesting  ideas  with  possible  market  potential 
that  would  not  be  found  through  other  conventional  methods.  These  ideas  go  to  the  marketing  to  see 
if  a  new  market  can  be  created. 

Beyond  the  basic  research  R&D  is  involved  in,  R&D  is  also  responding  to  technology-pull  from  the 
Marketing  department.  R&D  and  Marketing  agree  on  a  Technology  List.  The  List  consists  of  R&D 
and  also  major  development  products.  The  New  Product  List  contains  those  products  that  will  be 
delivered  to  market  within  2  to  4  years.  Usually,  the  New  Product  List  contains  overall  objective 
statements  for  the  new  products  (e.g.  performance  increased  by  10%,  removal  of  environmental 
hazards,  etc.). 

This  company's  Annual  Strategic  Planning  Process  coordinates  all  NPD  activities.  It  is  the  first  major 
input  into  the  produa  development  process  besides  NPD  ideas.  Strategic  planning  gives  direction, 
subtle  changes,  with  occasional  big  changes  (corrections),  mission  statements,  etc.,  for  the  whole 
company.  It  examines  what  the  broad  corporate  priorities  are,  and  what  part  of  the  business  they 
should  be  in.  It  discusses  any  key  issues,  concerns,  and  other  items  of  value  to  the  company. 
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The  annual  planning  process  proceeds  in  the  following  manner.  It  consists  of  a  document.  Many  of 
the  items  are  repeated  from  the  previous  year.  The  document  contains  the  vision  consisting  of  broad 
issues  and  direction  on  how  to  proceed  including  improvement  actions  (along  with  resources 
identified  to  do  it).  Major  new  products  are  part  of  the  plan.  The  document  is  actively  used.  The  plan 
might  have  a  general  strategy  for  a  new  product,  and  then  may  evolve  to  a  specialized  strategy  in 
subsequent  iterations  of  the  strategic  document.  Planning  is  a  continuous  process.  Another  issue  the 
company  is  focused  upon  revolves  around  how  to  make  sure  this  kind  of  validation  has  not  been  done 
somewhere  else.  In  terms  of  the  importance  of  speed  of  getting  products  to  market,  management 
communicates  the  importance  of  New  Product  Development  and  time  to  market  to  employees 
through  the  planning  process  as  well  as  other  means. 

The  strategic  planning  process  begins  at  the  beginning  of  the  company's  fiscal  year.  The  process  needs 
to  be  done  five  or  six  months  later.  However,  due  to  market  pressures,  now  it  is  not  uncommon  for  it 
to  be  completed  in  just  four  or  five  months.  The  process  starts  with  new  budgets  in  place  for  the 
coming  year.  Before  the  end  of  the  month,  the  Technical  List  is  given  to  the  Operations  Committee 
and  Business  Management.  Over  a  two-day  period  during  the  following  month,  Business 
Management  develops  Strategic  Options.  Early  the  next  month,  the  Preliminary  Product  List  is 
reviewed.  Late  in  the  following  month,  the  Lists  are  sent  to  the  Operating  Committee.  About  1 
month  later,  the  official  response  to  the  Lists  is  given.  At  the  five-month  point,  the  process  marks  the 
release  of  the  Tinal  6-year  Lists’.  Approximately  two  months  later,  the  Strategic  Business  Plan  is  sent 
to  the  CEO.  On  the  first  day  of  the  ninth  month  into  the  fiscal  year,  the  budgeting  process  begins  and 
the  various  budgets  for  the  different  business  units  are  finalized  just  prior  to  the  end  of  the  fiscal  year. 

Summary 

Company  A  process  generally  follows  the  concepts  of  the  notional  framework.  In  the  process  of 
identifying  requirements,  Company  A  was  very  adept  at  using  multiple  methods  to  gather  these 
requirements.  The  company  follows  a  formal  process  for  doing  so  and  uses  a  lot  of  market  research 
and  analysis. 
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Front-End  Process  Flow  Business  Case 


Figure  24.  Company  A's  Front-end  Process  in  Terms  of  the  Framework 


The  company  uses  a  screening  process  very  close  to  the  idealized  one  proposed  in  the  framework. 
Their  use  of  the  Lists  provides  the  traceability  into  the  disposition  of  each  projea  requirement.  It  also 
gives  management  the  ability  to  synchronize  new  product  releases  to  the  market  according  to  a 
schedule  they  would  like  to  do  so  as  well  as  maintaining  product  development  activities  are  conducted 
at  manageable  levels. 

Organizationally,  Company  A  is  attempting  to  improve  its  practices.  One  area  that  is  not  certain  is  the 
nature  of  the  teams  developing  solutions  for  requirements.  The  company  has  an  Executive 
Information  System  that  provides  holistic  information  to  management,  but  is  not  yet  available  to  most 
employees.  Having  one  organization  responsible  for  its  mamtenance  and  upkeep  is  important. 
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Company  B 

Company  B  is  a  large  Manufacturing/ component-assembly  Company  in  the  USA.  Its  products  are 
widely  regarded  throughout  the  world  and  enjoy  a  substantial  market  share  in  the  industry.  It  is 
focused  very  intently  on  the  Voice  of  its  Customers.  As  these  customers  can  be  very  demanding,  the 
company  spends  a  great  deal  of  its  time  and  resources  ensuring  it  understands  the  needs,  wants,  and 
desires  of  each  customer.  This  focus  has  notably  influenced  the  product  development  process  of  this 
company. 

The  company  has  a  small  percentage  of  its  overall  workforce  involved  in  Product  Development. 
Nevertheless,  the  development  of  new  products  and  further  development  of  the  company’s  existing 
products  is  an  important  part  of  the  company’s  operations  and  many  resources  are  dedicated  to  this 
purpose. 

Rather  than  refer  to  Requirements’,  the  company  prefers  to  call  them  ‘Criteria’.  The  company  found 
from  past  experience  that  using  the  term  'Requirements'  introduced  rigidity  into  their  processes. 
Requirements  tended  to  be  very  specific  and  changing  them  to  reflect  their  customer’s  latest  desires 
and  requests  were  very  painful.  ‘Criteria’  evoked  a  different  sort  of  response  within  their  development 
community.  A  criterion  is  seen  as  a  goal  to  be  achieved,  and  also  one  that  can  be  traded  against  other 
criteria  in  a  way  that  defuses  loyalty  and  the  politics  associated  with  a  Requirement’. 

The  front-end  product  development  process  of  this  company  is  a  convergence  of  two  activities,  the 
formal  product  development  process,  and  the  company's  strategic  process,  that  forms  a  virtual 
organization  charged  to  investigate  a  new  product  development  opportunity. 
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Figure  25.  Company  B's  Front-end  Process 


The  Product  Strategy  group,  part  of  the  Product  Development  organization,  spends  its  time  reviewing 
the  company  strategic  plan  and  the  current  market  conditions  for  opportunities.  Specifically,  since 
their  company  produces  platforms,  they  tiy  to  find  gaps  in  the  marketplace  the  company  can  then 
exploit. 

The  company  strategic  plan  has  a  20-year  forecast.  It  consists  of  short-term  and  long-term  plans  and 
forecasts.  The  focus  of  the  plan  is  on  the  first  ten  years  and  looks  at  high-level  items  like  technology, 
environment  concerns,  etc.  The  first  2  to  5  years  of  the  plan  are  more  specific,  but  are  known  for 
huge  fluctuations  from  iteration  to  the  next  iteration.  The  very  detailed  plan  only  forecasts  the  next  3 
months.  These  are  updated  constantly  the  time  to  reflect  the  most  current  conditions.  The  company 
releases  the  'official  strategic  plan'  annual^. 
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As  gaps  are  'found',  a  product  development  or  product  strategy  study  is  done.  A  Steering  Team  starts 
the  study.  The  team  is  made  up  of  several  lower  level  managers  within  the  product  development 
organization  of  the  company.  When  a  study  is  started,  a  team  is  organized  or  formed,  taking  some 
managers  (with  marketing  experience  &  understanding)  and  10  to  15  engineers  and  others  from 
different  disciplines.  They  act  as  integrators  of  information  and  call  upon  various  organizations 
(internal  and  external  to  the  company)  for  the  required  information  and  resources  that  would  be 
needed  for  future  development.  This  is  not  a  'separate'  team  or  organization,  hence  it  is  more  virtual 
than  real.  Another  reason  these  teams  are  virtual  is  due  to  the  time  spent  on  the  study.  Study  Times 
ranging  from  1  day  to  more  than  3  months  (in  calendar  time)  are  not  uncommon.  However,  some 
studies  are  considered  important  enough  that  a  dedicated  team  is  formed. 

Sometimes  studies  are  formed  at  the  direction  of  corporate  management  or  based  upon  customer 
feedback  gathered  by  the  formal  produa  development  process.  The  Steering  team  manages  all  these. 

The  Steering  team  will  also  approve  the  study  results  and  then  determine  whether  to  table  the  effort  or 
decide  that  it  has  potential  to  go  forward.  The  team  meets  weekly  and  reviews  the  progress  of  each 
study  and/ or  team.  If  a  decision  is  made  to  go  forward,  the  idea  or  item  that  generated  the  study  is 
further  developed  to  go  before  the  'Commitment  Board'.  Much  more  time  and  effort  is  made  to 
develop  the  idea  at  this  point.  Budgets  of  several  thousand  dollars  are  not  unusual  for  this  further 
development  stage.  The  board  is  very  busy  and  it  takes  about  a  month  to  get  on  the  calendar  of  this 
board.  The  package  that  is  then  presented  to  the  board  includes  market-driven  numbers  that  address 
costs,  revenue  stream,  ROI,  etc.,  and  generally  supports  the  idea  in  addition  to  the  technical 
information  previously  gathered  during  the  previously  mentioned  study.  ROI  has  generally  been  the 
real  differentiator  at  this  board.  The  board  is  the  corporate  forum  to  determine  which  projects  will 
receive  funding.  Membership  of  this  board  consists  of  the  company  department  vice  presidents. 
Approval  of  an  idea  by  this  forum  is  considered  to  be  the  first  part  of  the  business  case  decision  for 
the  project.  The  total  resources  required  are  allocated  for  the  project  (as  long  as  it  continues  to  meet 
development  goals  in  the  future). 

If  the  board  approves  the  idea,  marketing  takes  over  and  begins  to  'sell'  the  idea  to  its  customers. 
Marketing  will  develop  campaigns  for  each  customer  they  have.  Marketing  tries  to  put  the  selling 
points  of  this  new  idea  into  the  customer's  terms  and  aggressively  market  the  idea.  The  customer  team 
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(explained  in  depth  in  following  paragraphs)  is  responsible  for  selling  the  idea.  During  the  process  of 
selling  the  idea,  the  customers'  reactions  and  comments  are  recorded.  Marketing  tries  to  understand 
what  it  would  take  or  what  capability  would  be  required  in  this  new  product  for  this  customer  to  be 
interested.  Sometimes  customer’s  responses  will  trigger  the  launch  of  another  product  development 
study.  The  recorded  information  from  the  customer  becomes  part  of  the  input  to  the  formal  product 
development  process. 

The  narrative  above  described  only  the  process  required  for  marketing  to  win  approval  to  aggressively 
market  a  new  product  concept  to  its  customers.  The  following  paragraphs  detail  how  a  concept  is 
developed  and  a  business  case  for  the  concept  is  built  using  the  input,  feedback,  and  sometimes 
participation  of  its  customers,  in  addition  to  the  marketing  department  inputs. 

To  develop  a  comprehensive  set  of  prioritized  criteria  (requirements)  the  company  uses  a  formal 
process.  This  process  has  four  main  activities  -  Identify  Needs,  Translate  them  to  common  language. 
Integrate  various  sets  of  requirements,  and  Distribute  the  criteria  (requirements)  throughout  the 
organization.  Each  of  these  activities  has  several  sub-processes  or  tasks. 

‘Identify’  has  four  tasks:  Plan,  Collect,  Organize,  and  Concur. 

‘Translate’  has  two  tasks:  Convert,  and  Assimilate. 

‘Integrate’  has  three  tasks:  Consolidate,  Synthesize,  and  Rank. 

Distribute’  has  two  tasks:  Classify,  and  Distribute. 

The  company  believes  this  process  acknowledges  the  different  types  of  inputs  into  a  requirements 
system  or  process.  This  acknowledgement  of  the  various  inputs,  they  believe,  is  critical  to  the  success 
of  their  process.  It  avoids  surprises  and  pitfalls  that  otherwise  might  occur. 
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Although  the  material  will  be  treated  in  a  serial  fashion,  the  Identify  and  Translation  processes  are 
multiplied  according  to  the  number  of  input  sources  they  have  generally  and  not  just  for  a  particular 
project.  During  the  'Integrate'  phase  these  parallel  processes  will  converge  into  one  process  flow.  To 
further  illustrate  the  complexity  of  the  product  development  process  of  this  company,  at  any  given 
time  there  may  be  multiple  produa  development  processes  running  for  many  projects  in  development. 

Each  of  the  individual  input  sources  go  through  the  Process's  Identify  and  Translation  processes.  The 
results  are  separate  criteria  lists  for  each  constituency  or  input  source.  Some  of  the  inputs  are  Market 
Needs,  Regulatory  criteria.  Facility  criteria,  User  needs.  Manufacturer’s  knowledge  and  experience. 
Supplier  criteria,  and  Future  criteria.  The  synthesis  of  these  various  inputs  yields  the  ‘comprehensive 
set  of  prioritized  criteria'.  The  Comprehensive  Set  of  Prioritized  Criteria  contains  two  types  of  criteria: 
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Mandatoiy  and  Prioritized.  Mandatory  Criteria  are  needs  that  must  be  satisfied.  Prioritized  criteria  are 
“prioritized  needs  that  must  be  optimally  satisfied  such  that  they  do  not  negatively  impact  mandatory 
or  higher  prioritized  criteria.”  There  are  five  attributes  to  each  criterion:  traceability  to  the  source; 
specifications  (single,  multiple);  importance  rating;  rationale,  assumptions;  and  a  verification  plan. 

The  Tlan’  task  generates  a  list  of  questions  specifically  tailored  for  the  input  source  -  “What  do  you 
want?  What  are  your  needs?  How  would  such  and  such  capability  influence  your  satisfaction  with  our 
produas?”  This  is  done  by  striving  for  six  objectives:  preparing  a  list  of  company  needs  and  their 
associated  questions  to  be  asked  of  the  customer,  identifying  the  contact  objeaive;  identifying  the 
customer  and  company  personnel;  investigating  previous  contacts  -  ensuring  a  single  company  image; 
preparing  the  documentation;  and  determining  the  contact  logistics. 

‘Collect’  is  the  collection  of  the  needs  AND  the  assignment  of  an  importance  rating  to  each  listed 
criteria  from  the  input  source.  There  are  four  objectives  in  this  task.  The  company  wishes  to:  explain 
the  process;  provide  current  produa  information;  document  customer  needs;  and  solicit  relative 
importance  rankings.  The  importance  rankings  consists  of  the  following:  a  measure  of  the  significance 
of  each  need/criteria;  assigned  by  the  need/criteria  source;  applied  to  the  subject,  not  the  value;  and 
uses  a  five  category  scale.  The  scale  is  Listed  here: 

The  Need/ criteria  is  undesirable. 

The  Need/ criteria  is  not  important,  but  I  would  not  mind  having  it. 

The  Need/  criteria  would  be  nice  to  have,  but  it  is  not  necessary. 

The  Need/ criteria  is  highly  desirable. 

The  Need/ criteria  is  critical  to  have. 

‘Organize’  requires  building  a  database  of  the  information  collected  so  far  using  a  standard  template. 
This  forces  those  collecting  the  information  to  document  early  within  the  process  the  information  they 
have  received.  There  are  three  objectives  in  this  task:  Separate  the  different  inputs;  document  the 
customer’s  needs  and  the  company’s  understanding  into  a  database  system;  and  document,  resolve  and 
track  action  items. 
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According  to  the  company,  the  critical  part  of  the  process  is  in  the  next  task,  ‘Concur’.  This  is  when 
the  information  gathered  is  presented  back  to  the  input  source  and  each  individual  ‘criteria’  is 
reviewed.  It  has  three  objectives;  present  tbe  company’s  understanding;  ensure  a  single  voice  from  the 
customer;  and  obtain  and  document  concurrence. 

The  first  three  tasks  in  this  process  are  always  in  motion.  Any  member  of  the  company’s  marketing 
team,  engineering  staff,  and  anyone  else  that  might  have  interaction  with  the  customer  may  input 
information  into  the  process,  following  the  standardized  templates.  The  task  of  meeting  again  with  the 
customer  to  concur  happens  at  regular  intervals. 

Once  the  customer  has  agreed  with  the  information  presented  to  the  customer,  the  activity  of 
‘Translate’  begins.  The  first  task  in  this  activity  ‘converts’  the  information  into  ‘design  language  (target 
values)’.  This  task,  ‘Convert’,  has  four  objectives:  obtain  the  format  required;  convert  the  need  into  an 
item  which  is  understandable,  measurable  and  actionable  by  downstream  processes;  document  the 
conversion  methodology;  and  review  with  the  customer,  as  required. 

Oftentimes,  that  which  is  understandable,  measurable  and  actionable,  is  what  most  people  would  term 
a  requirement.  This  company  calls  ‘a  precise,  measurable  description  of  what  the  product  has  to  do  to 
satisfy  the  need/ criteria  a  ‘target  value’.’  The  target  value  is  based  on  customer  and  other  criteria 
source  needs;  company  objeaives  and  constraints;  and  competitor’s  capabilities.  These  are  sometimes 
stated  as  goals  over  and  beyond  a  minimum  value  based  on  wanting  to  offer  a  better  product  or  to  be 
more  competitive.  They  may  be  single  or  multiple  values;  a  range  of  values;  or  an  inequality. 
Generally,  these  are  labeled  with  the  appropriate  units  (i.e.  minutes,  kilograms,  etc.) 

The  second  task  of  this  activity,  ‘Assimilate’,  extracts  the  different  criteria  into  market  needs  and  also 
identifies/quantifies  the  variations  in  the  different  criteria.  This  task  has  six  objectives:  ensure 
consistency  of  the  converted  needs;  identify  the  relationship  between  the  needs;  evaluate  the  related 
needs  for  patterns  or  trends;  create  the  customer  market  need;  document  the  assimilation 
methodology;  and  review  with  the  customer,  as  required. 

A  key  milestone  is  reached  upon  completion  of  the  ‘assimilate’  task.  At  this  point,  management  must 
decide  the  future  direction  of  the  process.  They  can  allow  the  process  to  proceed  into  the  next  phases 
or  to  end  the  effort  or  even  redirect  it.  This  decision  point  is  the  second  one  made  by  the  senior 
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management  board  in  regards  to  nature  of  the  product.  It  is  the  same  board  that  approved  an  initial 
investigation  into  the  product  concept  (the  initial  business  case  decision).  The  decision  is  made  with 
the  different  'discoveiy  and  translate'  processes  coming  together  in  one  forum  to  present  a  'holistic' 
view  of  an  entire  project  in  a  series  of  separate  presentations.  Approval  to  proceed  constitutes  a 
validation  of  the  original  Business  Case  decision.  At  this  point,  the  company  resources  committed  to 
the  project  are  reevaluated  and  adjustments  are  made  as  necessary.  (Furthermore,  marketing  and 
contracts  will  begin  to  seek  customer  commitment  to  the  purchase  of  this  produa.  This  can  actually 
occur  at  the  first  business  case  decision  as  well  (and  might  be  required  in  order  for  the  projea  to  even 
enter  the  formal  product  development  process),  particularly  with  new  product  lines  or  platfonn 
introductions  by  this  company.) 

Additionally,  direction  might  be  given  by  the  board  to  conduct  trade  studies  on  different  criteria 
(requirements)  and  their  solutions.  These  can  be  new  criteria,  as  uncovered  during  the  discoveiy  and 
translation  processes,  or  can  be  on  derivations  of  a  'baseline'  criterion  set.  These  trade  studies  then 
follow  the  previously  outlined  process. 

The  rest  of  this  case  study  contains  a  description  of  their  regular  produa  development  process.  The 
description  is  included  because  of  the  aaivities  that  occur  here  while  in  other  company’s  processes 
these  aaivities  might  be  conduaed  in  the  front-end.  Upon  completion  of  the  Assimilate  task  and  the 
decision  by  the  board  to  proceed,  each  of  the  separate  input  sources’  wants  and  needs  should  be 
clearly  known. 

The  next  aaivity,  ‘Integrate’,  takes  all  of  these  criteria  and  ‘integrates’  them  into  a  common  Hst.  The 
task  of  ‘Consolidate’  is  a  compilation  of  all  of  the  coUeaed  criteria.  This  task  has  four  objeaives: 
combine  the  information  from  all  sources;  identify  the  relationships  between  the  customer  needs  and 
the  other  criteria;  categorize  the  criteria;  and  identify  the  hierarchical  relationships  between  the  criteria. 
The  task  ‘Synthesize’  has  different  objeaives.  There  are  four  of  them:  identify  patterns  or  trends 
within  each  category;  derive  the  single  criteria  within  each  category;  resolve  conflias  between  criteria; 
and  document  the  synthesis’s  rationale.  The  last  task  of  this  aaivity  is  ‘Rank’.  Here,  faaors  are 
applied  which  account  for  the  company’s  goals  and  objeaives,  according  to  the  following  areas: 
produa  strategy;  business  strategy;  timing;  customer  delight;  competition;  technical  charaaeristics;  and 
technology  level,  etc.  The  task  has  three  main  objeaives:  evaluate  how  well  the  criteria  satisfy  the 
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‘influencing  considerations’  or  factors;  document  the  rationale;  and  use  expert  judgement  to  sequence 
the  criteria  list.  The  analysis  is  accomplished  by  judging  how  well  the  criteria  addresses  the  influencing 
consideration  questions,  by  using  the  following  5  to  1  scale:  5= Very  Strong  or  Yes;  4= Strong; 
3=Medium;  2='Weak;  l=Very  Weak  or  No. 

The  last  activity,  Distribute,  is  focused  on  getting  this  information  to  the  right  places  within  the 
company.  The  first  task  of  the  activity,  ‘Classify’,  separates  the  ‘Must  Do’  criteria  from  those  that  are 
tradable,  or  the  mandatory  from  the  prioritized  ones.  This  is  another  screening  point  for  the  various 
criteria.  The  next  task,  although  it  does  not  affect  the  criteria  in  any  way,  is  still  the  responsibility  of 
the  product  development  organization.  This  task  is  to  ‘distribute’  the  information  and  has  four  main 
objeaives:  identify  which  process(es)  should  receive  the  information;  create  the  appropriate  format; 
distribute  the  information;  monitor  and  control  the  integrity  and  quality  of  the  information;  and 
measure  customer  satisfaction. 

The  entire  process,  although  it  is  iterative,  usually  takes  3  to  6  months,  depending  upon  the  complexity 
of  the  project.  The  company  judges  the  overall  process  on  two  merits:  how  well  the  customer  is 
satisfied  and  how  quickly  the  process  is  navigated. 

Once  the  criteria  have  been  fuUy  developed  and  finalized,  the  product  development  process  does  not 
end.  The  criteria  must  be  then  translated  into  detailed  design  decisions.  This  is  the  'Process  of 
Product  Configuration  Definition’.  This  seeks  to  develop  the  criteria  further  in  both  breadth  and 
depth.  Since  the  output  of  the  initial  process  in  the  front-end  is  a  definition  of  the  criteria  at  the 
product  level  (system  requirements  level),  the  next  step  is  to  define  the  high-level  functional  elements 
of  the  product.  This  is  followed  by  the  high  level  definition  of  the  physical  elements  of  the  product. 
This  development  continues  in  an  iterative  process  beginning  with  the  product  itself  and  then  working 
down  into  more  detail  at  the  system/ subsystem  level  and  then  finally  at  the  component  level.  Again, 
each  of  these  goes  through  a  funaional  definition  and  then  a  physical  element  definition  as  part  of  the 
'Process  of  Product  Configuration  Definition'. 

During  this  time,  it  is  likely  that  some  customers  may  provide  additional  input  to  the  process. 
Therefore,  the  company  has  developed  an  exhaustive  method  for  managing  customer  requirements.  It 
is  an  approach  and  strategy  of  mass  customization.  This  approach  maximizes  reusability  of 
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engineering  and  manufacturing  data,  while  allowing  customers  to  tailor  a  product  to  their  satisfaction. 
First,  as  much  as  possible  is  developed  by  designers  that  are  essential  basics  and  will  remain  stable  for 
the  product  (a  no-frills  version  of  the  product).  Second,  many  optional  features  are  designed  up-front, 
but  the  added  costs  (including  development  costs)  for  these  options  are  passed  directly  on  to  the 
customer  choosing  that  particular  option.  Finalfy,  customer-unique  options/ requests  absorb  the  fuU 
cost  of  development,  engineering  and  manufacturing  operations  for  that  option.  A  unique  feature  or 
option  request  is  the  most  expensive  option  for  a  customer  to  choose.  This  strategy  allows  the 
company  to  keep  the  unit  costs  of  its  products  low  rather  than  forcing  all  of  its  customers  to  pay 
development  costs  for  features  that  are  only  required/ requested  by  a  few  customers.  In  some  sense 
this  is  a  produa  customization  strategy  or  a  product  line  differentiation  strategy. 

Organizational  Issues 

The  company  uses  ‘customer  teams’  in  the  product  development  process.  These  teams  are  made-up 
of  individuals  from  Customer  Engineering,  Marketing,  Customer  Services  (support).  Sales,  Customer 
Relations,  Marketing  Management,  and  Contracts.  These  teams  are  most  often  focused  during  the 
Discover  stage  of  the  produa  development  process  and  also  the  most  stable.  In  some  cases,  these 
teams  'know'  their  customers  and  how  th^  are  using  the  company's  produas  better  than  their 
customers  do.  As  the  process  progresses  into  the  downstream  stages,  the  composition  of  the  'team' 
that  develops  the  requirement  changes  (it  is  a  new  produa  development  team),  but  the  produa 
development  team  still  maintains  links  with  the  customer  team  to  ensure  the  correa  feedback  (i.e. 
sanity  checks)  occurs  with  the  customer. 

The  organizational  group  that  controls  the  produa  development  process  is  multi-disciplinary.  This 
organization  could  not  entirely  absorb  marketing,  service,  support,  supplies,  etc.,  but  the  organization 
brought  in  numerous  representatives  from  these  other  organizations  to  ensure  the  broadest  multi¬ 
disciplinary,  cross-funaional  base  possible  for  the  development  of  produas  for  the  company. 

By  design,  the  process  tries  to  be  simple.  The  Produa  Development  Organization  believes  it  must  be 
kept  so,  otherwise,  manufacturing  as  well  as  produa  design  engineers  will  'get  ahead'  of  the  process. 
As  the  'clockspeed'  of  this  industry  increases  because  of  the  shortening  technology  development 
cycles,  Produa  Development  is  constantly  seeking  ways  to  improve  the  produa  development  process 
and  keep  its  cycle  time  low. 
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From  an  organizational  standpoint,  this  company  has  endured  some  painful  adjustments.  It  has 
recently  completed  an  organizational  shuffle  that  drastically  altered  the  way  the  company  was 
organized.  It  was  implemented  in  January  1999.  In  some  respects,  this  change  recognized  the  product 
development  process  that  had  evolved  over  the  years,  and  now  aligned  the  organizations  properly. 
Previously,  the  company  had  been  entirely  organized  around  functional  departments  and  also  produa 
teams.  Duplication  of  effort  and  waste  of  resources,  not  to  mention  customer  dissatisfaction  were 
reasons  for  the  reorganization.  The  new  organization  brought  portions  of  Marketing  within  the 
Product  Strategy  &  Development  organization  of  the  company.  These  portions  were  those  of 
marketing  that  concerned  themselves  with  marketing  specific  products  and  customer  requirements  as 
well  as  strategy  planners  for  their  produas  and  features.  This  new  organization  was  designed  to 
eliminate  the  multiple  company  representatives  that  would  call  on  customers.  One  customer  once 
complained,  “You’re  the  seventh  person  I’ve  talked  to  and  I’ve  yet  to  see  this  resolved.” 

The  other  major  change  was  the  dissolution  of  product  organizations  and  realignment  into  platform 
organizations.  The  hope  was  to  avoid  the  costly  duplication  of  different  designs  for  common  elements 
of  their  products.  For  instance,  two  product  elements  currently  exist  that  have  the  exact  same 
dimensions  as  well  as  the  same  requirements  for  performance.  From  an  appearance  standpoint,  they 
are  not  distinguishable  from  one  another.  In  terms  of  performance,  these  products  perform  identical 
tasks.  Yet,  these  produa  elements  are  manufactured  differently  and  are  not  interchangeable  with  one 
another. 

Business  Issues 

There  are  approximately  20  people  in  the  management  group  of  the  produa  development  process  of 
the  company.  These  people  come  from  the  corporate  levels  of  the  company  and  control  the  process. 
They  exercise  control  over  the  process  by  having  lots  of  reviews  and  management  oversight. 

Resources  for  the  produa  development  process  come  from  the  different  produa  lines  of  the 
company.  The  share  of  resources  produa  development  gets  depends  upon  how  well  the  produa  is 
doing  in  the  market.  This  faa  tends  to  influence  produa  development  to  'heed'  its  larger  benefaaors 
more  than  other  produa  lines  that  don't  contribute  a  lot  of  resource  to  the  process.  In  the  case  of  a 
new  produa  line  launch,  the  resources  come  from  overall  corporate  resources. 
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The  company  has  been  using  a  common  IT  solution  for  their  'criteria'  (requirements),  their 
development,  and  translation  into  technical  specification  (DOORS).  Traceability  is  of  primary 
importance  -  all  the  way  back  to  the  customer  source.  They  currently  have  plans  to  deploy  this  tool 
(or  a  module  of  it)  into  the  hands  of  their  customers  as  soon  as  they  can  ensure  the  security  of  each 
customer's  data. 

Furthermore,  they  are  moving  from  400+  computing  systems  to  one  networked  computer  system, 
responsible  for  the  creation  of  a  single  bill  of  materials  vs.  hundreds  of  them.  This  computmg  system 
is  for  all  company  scheduling,  ordering,  purchasing,  and  production  of  its  products.  The  outcome  wfU 
be  reduced  product  production  flow  times. 

Summary 

Company  B  has  a  formal  product  development  process.  Only  in  the  past  year  has  the  front-end 
process  been  integrated  into  the  same  organizational  structure  as  their  formal  product  development 
process.  Because  of  this,  it  is  not  yet  certain  how  effective  company  B  has  been  in  its  recent  efforts. 
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Figure  27.  Company  B's  Front-end  Process  in  Terms  of  the  Framework 


Overall,  the  design  and  operation  of  company  B's  process  mirrors  the  process  framework  presented 
earlier.  Unique  elements  are  those  that  reflect  the  overall  position  of  the  company's  close  ties  with 
their  customers.  The  additional  review  gate  for  the  business  case  between  in  the  front  end  and  the 
first  review  gate  in  the  product  development  process  seems  to  be  a  risk  mitigating  approach.  This 
would  be  especially  tme  for  new  produrt  lines  where  the  development  costs  are  huge.  It  appears  the 
efforts  done  during  the  front-end  are  to  develop  and  gain  the  confidence  of  the  company's  engineers 
and  technicians.  The  final  business  case  preparation  period  seems  to  be  conducted  to  convince  their 
customers  that  the  company  is  up  to  the  technical  challenges  and  also  to  include  them  in  the 
exploration  process  of  the  opportunity  space. 
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Company  C 

Company  C  is  a  materials  science  company  that  is  in  the  defense,  telecomm,  and  consumer  electronics 
industry  as  a  maker  of  a  broad  range  of  high  performance  accessory  produas.  It  has  its  headquarters 
on  the  West  Coast  of  the  United  States.  The  description  of  the  process  used  in  the  front-end 
development  of  new  projects  is  based  upon  activity  prior  to  its  recent  acquisition  by  another  company. 

The  following  graphic  depicts  the  process.  The  detailed  explanation  of  the  overall  process  is  found 
below. 
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Figure  28.  Company  C  Front-end  Process 


The  company  uses  several  processes  to  get  New  Product  Development  Projects  going.  The  first  piece 
of  the  process  is  the  strategic  plan  of  the  company.  Part  of  that  plan  specifically  addresses  areas  for 
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growth  (new  markets,  existing  markets  -  existing  customers,  existing  markets  -  new  customers).  The 
strategic  plan  has  a  horizon  of  five  years  and  is  done  annually.  March  1  is  the  beginning  of  the 
planning  cycle  and  July  1  is  the  start  of  the  fiscal  year.  AH  planning  must  be  done  prior  to  July  1. 

The  second  piece  of  the  process  is  the  company’s  use  of  a  business  operations  plan.  It  has  a  two-year 
horizon.  Oftentimes,  it  is  really  just  a  one-year  plan.  The  plan  is  created  annually  (with  2  years  worth 
of  projections),  but  is  revised  often  between  the  formal  revisions.  This  plan  is  used  to  actually  disperse 
money  according  to  the  company’s  business  objectives.  It  seeks  to  implement  the  vision  and  goals  of 
strategic  plan  in  a  realistic  manner. 

The  marketing  department  actively  scmtinizes  the  strategic  plan  of  the  company.  A  market  team  will 
examine  the  market  and  try  to  flush  out  opportunities  that  are  in  harmony  with  the  overall  strategic 
plan.  As  opportunities  arise,  marketing  will  approach  one  of  the  development  organizations  within  the 
company  (that  is  likely  most  aligned  with  the  new  opportunity  or  idea),  and  solicit  its  support  (money 
and  personnel)  to  evaluate  the  opportunity.  This  is  the  feasibility  evaluation.  It  is  done  for  every  new 
idea  or  product  opportunity.  A  team  of  individuals  does  this,  a  marketing/sales  person  and  a 
rtiinimum  of  at  least  one  technical  person.  It  is  not  uncommon  for  these  teams  to  contain  only  two 
members.  Once  established,  these  teams  remain  in  place  until  the  feasibility  study  results  in  an 
approved  projea  or  is  terminated.  The  personnel  on  the  teams  rarely  change,  rather,  they  gain 
experience  working  together  on  different  feasibility  evaluations. 

The  reports  summarizing  these  studies  are  only  2  to  3  pages  long.  Several  criteria  are  used  to  prepare 
the  evaluation  and  will  be  the  same  ones  used  during  the  project  evaluation.  These  are:  the  clarity  of 
the  opportunity;  the  reasons  to  begin  the  project  now;  how  it  addresses  the  skills  and  strengths  of  the 
firm;  the  opportunity  that  exists  in  the  market;  the  complexity  of  the  project;  and  how  long  it  wiU  take 
to  complete  development.  The  answers  to  these  criteria  build  the  business  case  of  the  project.  Some 
of  the  outputs  of  the  stuc^  include  a  5  year  income  statement  projection,  NPV,  IRR,  Cash  flows,  etc. 

The  costs  for  these  studies  are  usually  absorbed  by  one  of  the  development  organizations  in  the 
company.  However,  occasionally  another  organization  wiU  pay,  as  the  cost  of  such  studies  is  generally 
not  high.  Unfortunately,  sources  of  funding  are  not  always  secure  or  guaranteed.  Typically,  the  issue 
revolves  around  which  organization  should  piey  for  the  evaluation  vs.  the  expeaed  return  of  the 
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evaluation.  Despite  this,  attractive  opportunities  always  seem  to  get  funded  through  the  feasibility 
stage. 

A  Product  Approval  Committee  reviews  the  business  case  of  each  feasibility  evaluation.  The  general 
manager  of  each  division  sits  on  this  committee.  It  meets  on  a  regular  basis,  typically  once  a  month. 
In  these  reviews,  projects  are  killed  if  there  is  a  compelling  reason  to  do  so,  like  one  of  the  previously 
mentioned  criteria  being  completely  out  of  acceptable  ranges,  particularly  the  financial  estimates. 
Approval  of  a  study  sends  the  project  into  the  familiar  stage-gate  process  widely  in  industry  use.  The 
design  review  process  is  separate  and  deals  with  more  of  the  technical  details  and  is  conducted  as  part 
of  their  stage-gate  product  development  process. 

The  stage-gate  process  is  very  typical  for  their  development  products.  A  distinguishing  feature  of  their 
process  adds  criteria  to  the  previously  explained  list  of  criteria  at  each  subsequent  gate.  The  project’s 
performance  is  compared  from  gate  to  gate,  stage  to  stage.  The  figures  in  the  original  study  are  always 
revisited  and  revised  at  each  gate. 

Orgamzationd  Issues 

The  Product  Approval  Committee  has  also  developed  a  rule  of  thumb  or  a  heuristic  for  its  use.  After 
a  period  of  time,  the  committee  begins  to  distinguish  the  figures  coming  from  individual  teams.  It  has 
developed  from  experience  the  knowledge  that  some  teams  are  more  aggressive  than  others  are,  and 
some  teams  have  ‘softer  numbers’  than  others.  The  Committee  takes  this  into  consideration  when 
making  decisions. 

The  teams  used  to  conduct  the  feasibility  evaluations  have  also  developed  some  rules  of  thumb.  One 
is  to  take  more  time  up-front  before  a  potential  project  goes  to  the  Product  Approval  Committee. 
Another  is  that  senior  employees  with  a  lot  of  experience  should  always  manage  teams.  They  must 
have  experience  in  the  area  under  consideration  as  well.  Junior  employees  are  alwsys  part  of  the  team, 
but  do  not  hold  leadership  positions.  In  this  w^,  a  form  of  mentoring  takes  place  within  the  team. 

Business  Issues 

The  overall  cycle  time  from  ‘gleam  in  the  eye’  to  the  business  case  decision  is  only  a  few  months.  The 
average  is  3  months  with  a  normal  distribution. 
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The  company  believes  it  has  a  very  active  front-end.  The  company  expects  to  see  a  lot  of  activity  here 
and  lots  of  projects  under  evaluation.  If  there  is  not  a  lot  of  activity  here,  action  will  be  taken  to 
reinvigorate  the  front-end.  Nevertheless,  the  different  projects  are  expected  to  be  filtered/funneled 
out  as  they  move  along  the  new  product  development  process.  So,  they  track  the  number  of  projects 
at  each  stage  of  development  vs.  a  historical  trend  for  each  stage.  Goodness  is  measured  by  a 
decreasing  number  of  active  projects  the  further  into  the  product  development  process  the  project  is. 

Another  metric  is  the  numbers  of  ideas  undergoing  exploration  vs.  those  that  are  already  in  the 
process.  It  is  related  to  the  metric  described  above,  but  specifically  focuses  on  the  ‘robustness’  of  the 
front-end.  Simple  graphing  of  this  metric  can  serve  as  a  visual  indicator  for  the  company’s  decision¬ 
makers.  Very  quickly,  the  company  can  ascertain  its  NPD  health  by  knowing  what  things  are  in  the 
‘pipeline’  or  about  to  enter  it. 

The  last  metric  of  note  is  the  tracking  of  ‘seed’  activities.  These  are  projects  that  currently  don’t  fit 
into  the  corporate  vision  of  the  company  nor  have  a  commercial  vehicle  to  take  it  to  market. 
However,  the  ideas  are  interesting  with  tangible  commercial  possibilities  and  potentially  could  develop 
into  a  project.  A  small  amount  of  seed  money  is  set  aside  to  further  explore  these  ideas.  Additionally, 
these  ‘seed’  activities  are  not  likely  to  be  completed  within  the  typical  3-month  process  cycle  time. 
When  the  activity  is  complete,  the  Produa  Approval  Committee  makes  a  decision  whether  or  not  to 
pursue  it  further  using  the  regular  process. 

Summary 

This  company’s  process  incorporates  many  of  the  features  of  the  ideal  process  outhned  in  the 
framework.  Some  of  the  unique  features  of  this  company’s  process  are  the  metrics  outlined  above. 
Additionally,  the  recognition  of  the  feasibility  teams’  personalities  and  work  and  how  it  impacts  the 
review  of  their  work  by  the  Product  Approval  Committee  is  noteworthy. 

The  relationship  between  this  company’s  front-end  process  and  the  idealized  framework  are 
highlighted  below. 
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Figure  29.  Company  C's  Front-end  in  Terms  of  the  Framework 

The  company  has  only  one  formal  screen  done  by  its  product  approval  committee.  There  is  no 
corollary  to  the  screening  stage  of  the  framework,  however,  the  activities  that  occur  during  that  time, 
according  to  the  process  maturity  matrix,  are  spread  through  the  other  three  framework  aaivities 
within  the  company’s  process. 

The  company’s  process  contains  areas  of  concern,  particularly  the  potential  for  ‘in-fighting’  within 
development  organizations  regarding  the  funding  of  these  up-front  studies.  Another  area  of  concern 
is  the  organizational  relationship  between  finding  ‘market  opportunities’,  conducting  the  feasibility 
stucfy-,  and  the  regular  product  development  process.  Potentially  there  are  three  different  organizations 
involved  in  the  entire  process.  The  last  area  of  concern  is  the  lack  of  continuity  between  the  work 
done  by  the  team  during  the  feasibiKty  evaluation  and  its  transition  to  a  new  product  development 
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team  in  the  regular  product  development  process.  However,  this  is  generally  a  non-issue  as  the 
feasibility  team  typically  becomes  the  nucleus  of  the  product  development  team. 

Company  D 

Company  D  is  a  computer  software  company  providing  solutions  for  business  and  personal  use.  It  is 
a  subsidiary  of  a  Fortune  100  company.  It  is  headquartered  in  the  USA. 

Company  D’s  process  at  a  glance  is  not  as  structured  as  other  firms’  processes.  A  select  few 
individuals  make  most  of  the  decisions,  and  these  are  done  based  upon  a  business  case.  However, 
their  process  is  one  that  they  believe  will  allow  them  to  compete  most  effectively  in  their  market  space. 

The  following  diagram  and  following  description  explains  their  process. 
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Figure  30.  Company  D's  Front-end  Process 
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A  Senior  Executive  Staff,  consisting  of  all  of  the  vice  presidents  of  the  company  and  the  company’s 
product  managers,  once  a  year  determines  strategic’  directions  for  the  company  and  then  ‘tactical’ 
decisions  are  made  at  lower  levels.  Examples  of  ‘strategic’  decisions  include  the  approval  of  new 
product  development  activities  and  vision  statements.  Examples  of  ‘tactical’  decisions  are  working 
upon  product  upgrades  and  feature  improvements,  customer  support  and  which  features  to  pursue. 

The  developer  of  a  business  case  is  usually  one  person.  According  to  the  company,  80%  of  the 
company’s  ideas  for  both  new  products  and  features  come  from  the  bottom-up  (a  software 
programmer).  These  plans  are  put  together  by  people  at  the  lowest  level.  Another  18%  are  specific 
inputs  from  their  customers  and  again  are  fielded  by  lower-level  employees.  Only  about  1%  come 
from  the  executive  level  and  are  pushed  on  down.  Therefore,  practically  all  product  development 
activities  come  from  the  lower-level  employee  and  is  also  the  most  likely  to  build  the  business  case. 

Most  business  plans  are  developed  within  4  weeks  by  the  originator  or  the  employee  that  fielded  the 
specific  input  from  the  company’s  customer.  This  includes  analyzing  the  data,  putting  together  the 
report,  coming  up  with  their  recommendations,  and  choosing  the  best  alternative.  No  formal  team  is 
put  together,  but  employees  often  seek  each  other  for  help  with  various  aspects  of  the  business  plan 
on  an  as  needed  basis.  (A  new  employee  would  seek  help  often  and  a  more  experienced  one  would 
likely  not  need  to  do  so.)  With  partners  outside  of  the  company,  these  plans  can  take  longer,  but  no 
more  than  7  months.  If  a  radical  innovative  plan  is  being  put  together,  it  would  take  anywhere  from  7 
to  9  months. 

The  business  case  is  built  upon  a  lot  of  analysis.  This  is  because  decisions  about  the  business  plans  are 
based  upon  several  standard  criteria:  cost  (of  development),  the  time  to  market  (the  cost  of  delay),  and 
the  revenue  potential.  The  money  required  vs.  revenue  potential  is  the  biggest  factor  in  the  process. 

Lastly,  if  there  is  a  new  opportunity  identified,  and  it  is  in  an  area  the  company  is  well  established  and 
has  a  lot  of  experience  in  that  market-space,  the  supervisor  of  the  employee  will  direct  the  employee 
developing  the  idea  to  not  do  a  full  business  plan  with  analysis.  Instead,  a  simple  business  case  with 
just  the  overall  information  about  the  potential  returns  and  development  cost  is  used  and  is  all  that  is 
needed.  Entirely  new  business,  however,  must  go  through  the  rigor  of  the  up-front  analysis. 
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when  a  business  plan  is  being  debated,  the  process  lasts  2  to  3  weeks.  Most  of  the  discussion  done  at 
the  Senior  Executive  level  is  about  the  validity  of  the  data.  They  do  not  debate  the  product  features; 
they  feel  it  is  best  left  at  the  lowest  levels  of  the  company. 

The  actual  plan  of  developing  the  new  produrt  is  much  different  than  the  business  plan.  They  feel 
that  otherwise  the  effort  would  become  compromised.  Furthermore,  if  one  of  the  several 
development  organizations  is  unable  to  develop  a  new  product  according  to  cost  and  schedule 
constraints,  the  company  will  threaten  (and  has  done  so)  and  actually  move  the  development  to 
another  organization.  Their  belief  is  that  they  should  treat  their  developing  organizations  much  as  a 
customer  of  theirs  would  treat  the  company  if  it  were  not  performing.  The  result  of  this  external 
threat  is  that  there  is  little  requirements  creep  or  growth  beyond  the  initial  approved  set  at  the  outset  of 
a  project. 

OrgamTotioml  Issues 

In  this  process,  decision  making  is  pushed  down  as  far  as  possible  -  to  supervisors  of  software 
programmers.  This  empowers  the  lower  level  of  the  organization  to  work  within  generally  defined 
spaces,  but  to  pursue  opportunities  perhaps  unforeseen  at  higher  levels.  The  organization  reinforces 
the  concept  that  the  developers  really  understand  the  user  needs  and  requirements  much  better  than 
an  executive  staff.  The  staff  merely  decides  if  the  potential  returns  and  overall  commitment  of 
company  resources  is  in  harmony  with  the  overall  vision  and  outlook  of  the  company. 

Also,  decisions  to  pursue  opportunities  for  new  produas  or  other  product  enhancements  are  made  at 
the  lowest  level.  The  programmer  that  wishes  to  pursue  this  opportunity  determines  with  the  help  of  a 
supervisor  whether  or  not  it  fits  the  criteria  of  ‘being  within  one  of  the  company’s  well-established 
market  spaces’.  Regardless  of  the  approach  used,  the  proper  business  ‘numbers’  (return  and 
investment  costs)  have  to  be  provided  to  the  company’s  leadership  so  they  can  make  a  final  decision. 

It  appears  that  partnering  with  other  organizations  increases  the  complexity  of  the  process.  Perhaps 
this  is  a  reflection  of  the  consensus-building/networking/advocacy  environment  present  in  this 
process.  A  process  that  normally  takes  1  month  to  complete  may  now  take  up  to  7  months. 
Additionally,  major  new  produa  development  projerts  (with  new  software  architectures  or  reusing 
existing  platforms)  seem  to  force  tremendous  turmoil  into  the  process  because  of  all  of  the  different 
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interactions  with  other  projects  and  company  products.  In  such  cases,  the  overall  process  may  require 
7  to  9  months. 

Business  Issues 

The  process  to  make  business  decisions  for  New  Product  development  has  a  cycle  time  of  about  6 
weeks.  This  happens  in  an  industry  where,  according  to  company  information,  product  development 
cycles  last  12  months  and  product  lifecycles  are  about  3  years.  Total  overall  cycle  time  is  3  Vz  years  - 
from  idea  to  retirement  of  the  product. 

This  company  has  a  Spring  and  Fall  Plan  as  part  of  the  company’s  budgeting  and  strategic  planning 
process.  The  Spring  Plan  is  a  two-year  outlook  and  contains  broad  strategic  objectives.  This  plan  is 
actually  put  together  by  the  parent  company.  Money  is  allocated  according  to  this  plan  in  broad 
generalities  (i.e.  existing  project  groups,  planned  new  product  development  projects,  and  management 
reserve). 

The  company’s  fiscal  year  begins  on  July  1  of  each  year.  However,  the  company  operates  (and  spends 
money)  on  a  calendar  to  calendar  year  basis.  The  Fall  Plan  explains  this  strategy.  During  the  build  of 
the  Fall  Plan,  3  to  5  days  are  needed  to  determine  where  the  money  will  go.  Other  business 
opportunities  are  identified  at  this  time  as  well.  This  point  in  the  process  is  where  the  new  product 
development  ideas  receive  funding. 

Additionally,  new  product  development  ideas  with  accompanying  business  cases  can  come  up  at  any 
time  of  the  year.  When  this  happens,  the  fall  plan  is  flexible  enough  that  according  to  the  judgement 
of  the  Senior  Executive  Staff,  money  can  be  reallocated.  According  to  the  company,  failure  to  have 
this  kind  of  flexibility  in  the  changing  market  they  are  in  can  mean  the  difference  between  succeeding 
as  a  company  or  being  forced  out  of  the  business. 

Summaty 

Q)mpany  D  believes  its  survival  and  competitive  advantage  comes  from  the  unstmctured  nature  of  its 
front-end  and  from  the  relative  autonomy  granted  the  individual  employees.  In  comparison  with  the 
framework,  as  the  diagram  below  attempts  to  illustrate,  these  ideas  have  the  biggest  impact  on  the 
company’s  process  and  are  the  sources  of  the  main  points  of  differentiation  from  the  suggested  ideal 
process.  The  most  obvious  point  of  differentiation  is  during  the  screening  phase  when  a  supervisor 
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assumes  this  role.  The  distinction  between  this  company’s  process  and  the  framework  is  that 
screening  decisions  are  made  in  light  of  the  entire  product  development  stream.  This  company’s 
process  allows  any  idea  that  looks  good’  to  go  forward.  7\jiother  impact  is  the  relationship  the 
company  has  with  its  parent  company  and  the  financial  implications  of  that  relationship.  The  parent 
company  has  always  used  a  stage-gate,  phased-development  product  development  process.  It  has 
expressed  dissatisfaction  with  this  company’s  process  and  uses  every  opportunity  to  scrutinize  it. 
Nevertheless,  this  company  is  quick  to  point  out  the  process  used  by  the  parent  company  is  considered 
unwieldy  and  that  it  removes  decision  power  from  those  who  know  best  (the 
employees/ programmers/ users). 


Figure  31.  Company  D's  Front-end  Process  in  Terms  of  the  Framework 


The  same  person  or  groups  of  people  that  originally  developed  the  business  case  for  the  idea  conduct 
product  development.  They  do  the  work  required  to  take  the  idea  from  conception  to  the  market. 


146 


Organizational  issues  such  as  knowledge  transfer  and  requirements  creep  are  possibly  minimized 
because  the  same  individuals  are  involved  in  the  project  from  the  beginning. 

The  method  by  which  New  Produa  Ideas  are  processed  introduces  the  concept  of  the  Process  Takt 
Time.  Although  the  overall  process  from  ‘dream’  to  business  case  is  typically  about  6  weeks,  new 
produa  development  projeas  are  usually  ‘started’  (i.e.  receive  funding)  once  a  year.  So,  the  Takt  time 
of  the  process  is  actually  one  year.  Of  course,  the  company  has  measures  in  place  to  begin 
development  work  on  other  projeas  throughout  the  year  (i.e.  a  management  reserve,  flexibility  in  the 
Fall  Plan,  etc.).  A  further  mitigating  faaor  is  also  the  relationship  between  the  company  Spring  and 
Fall  Plans.  Special  funding  can  be  received  when  absolutely  necessary  through  the  Spring  Plan 
mechanism  with  the  parent  company. 

Company  E 

Company  E  is  a  computer  manufacturing  company  that  deals  with  all  aspeas  of  the  computer.  They 
manufacture  their  own  hardware  and  software  systems.  The  company  is  considered  one  of  the  major 
players  in  the  computer  industry  and  has  locations  throughout  the  country.  The  company  is  organized 
into  several  operating  divisions  or  separate  business  units.  The  Corporate  Headquarters  are  in  the 
western  USA. 

There  is  no  formal  'process'  of  New  Produa  Development  for  the  entire  company,  although  initiatives 
are  underway  to  develop  a  common  phase  release  policy  and  pilot  projeas  are  prototyping  this 
approach.  However,  there  is  an  accepted  framework  for  developing  ideas  and  choosing  the 
engineering  solution.  From  within  this  accepted  framework,  the  business  plan  is  developed.  The 
framework  does  not  diaate  how  to  navigate  the  'informal'  process;  rather  it  provides  suggested 
methods  to  use  in  developing  the  business  plan.  Each  operating  unit  or  division  is  allowed  to  locally 
interpret  the  framework.  Oftentimes,  according  to  a  company  source,  the  company  seems  to  operate 
in  an  ad  hoc  fashion  m  regards  to  new  produa  development  decisions. 

The  following  diagram  illustrates  the  general  front-end  in  use  by  this  company. 
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Figure  32.  Company  E's  Front-end  Process 

The  company  is  driven  strategically  from  three  areas:  Technology  trends  (i.e.  Moore's  Law  -  doubling 
of  processor  speed  every  18  months);  technology  focus  (the  vision  for  the  company  in  3  to  4  years); 
and  evolving  standards  for  computer  components  (both  hardware  and  software).  The  key  challenge 
facing  this  company  is  a  produa  development  cycle  that  exceeds  the  market  life  of  the  product  (i.e.,  it 
takes  2-4  years  to  develop  a  next  generation  produa  which  may  only  have  a  useful  revenue  life  of  1-2 
years).  Hence,  there  is  a  great  deal  of  uncertainty  about  the  market,  competition,  standardization  and 
customer  throughout  the  early  stages  of  a  produa’s  life.  The  lack  of  a  formal  process  is  considered  an 
asset  by  some  in  allowing  flexibility  and  speed  in  addressing  new  information,  as  it  becomes  available 
without  rigid  rules  for  dealing  with  exceptions. 
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The  process  leading  to  the  completed  business  plan  consists  of  three  phases:  Projea  Investigation 
(analysis  of  technologies  and  concepts  vs.  needs);  Projert  Initiation  (comes  up  with  a  suite  of  solutions 
matched  to  the  identified  needs);  and  then  the  Project  Plan  (containing  the  chosen  feature 
set/ requirements).  In  the  first  two  steps,  cost  is  only  a  guide.  In  the  last  step,  cost  is  veiy  important  as 
the  entire  budget,  financial  analysis,  NPV,  etc.,  is  based  upon  this. 

Informally,  these  steps  have  other  names.  The  first  step  is  called  the  "Up-front  Process".  The  second 
step  is  the  "Generation  of  Concepts"  stage.  The  last  step  is  the  "Project  Approval  Process".  The 
boundaries  between  these  steps  are  not  well  defined  and  it  is  difficult  to  quantify  where  one  ends  and 
one  begins.  However,  the  Project  Approval  Process  requires  an  end  document  that  is  rigorous  and 
complete,  suitable  to  aa  as  the  contract  between  the  product  development  team  and  the  corporation. 

Sources  of  ideas  for  new  products  are  varied.  Because  of  the  highly  volatile  nature  of  this  industry, 
many  ideas  come  directly  from  the  trends  seen  in  the  marketplace.  C>thers  come  from  feedback  from 
customers,  and  stiU  other  sources  are  those  from  within  the  company  (R&D  and  also  directly  from 
other  employees).  There  are  many  more  ideas  and  opinions  than  resources  to  chase  them,  so  filtering 
these  inputs  are  extremely  critical. 

Ideas  explored  in  the  Project  Investigation  phase  are  generated  in  a  bottom-up  fashion,  usually  from 
within  the  technical  ranks.  Very  few  are  top-down  directed.  Each  product  group  within  the  company 
is  expected  to  devote  small  amounts  of  time  as  well  as  resources  to  developing  other  ideas  without 
getting  approval  from  upper  management.  Usually  this  is  in  the  form  of  'spare'  time  and  isn't  formally 
tracked  by  the  company. 

As  the  idea  matures,  and  the  idea  champion(s)  believes  there  is  merit  to  the  idea,  funding  is  sought. 
This  is  the  beginning  of  Projert  Initiation.  The  champion  gathers  some  rough  information  about  the 
idea  and  presents  it  to  a  decision-making  forum.  The  decision  to  pursue  this  projert  is  made  by  the 
division  Vice  President. 

The  Vice  President  of  the  division  or  operatiug  group  holds  weekly  strategy  meetings.  The  meeting 
serves  as  a  heading  check  on  aU  of  the  different  projects  that  are  underway  at  any  given  time,  as  well  as 
being  the  approval  point  for  any  new  projects.  The  focus  is  on  the  revenue/profit  potential  of  any 
given  projert.  However,  the  decisions  on  product  requirements  and/ or  product  features  are  left  in  the 
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hands  of  the  technical  community.  Company  E  manages  this  process  by  keeping  track  of  the  number 
of  projects  in  the  development  process,  and  not  letting  too  many  into  development.  With  approval, 
formal  team  formation  occurs  (or  is  acknowledged)  and  the  idea  is  developed  further.  It  is  typically  at 
this  time  when  the  formal  assignment  of  a  program  manager  occurs. 

Additionally,  a  strategy  committee  meets  on  a  regular  basis  to  discuss  among  other  items,  issues  of 
cost,  quality,  produa  availability,  time  to  volume,  and  the  strategic  focus  of  their  products.  Due  to  the 
influence  of  the  strategy  meeting,  the  company  has  a  rolling  product  priority  list.  It  is  updated  on  a 
monthly  basis. 

During  the  phase  of  Project  Initiation,  two  different  types  of  analyses  are  done.  These  are  the 
'Operational'  and  'Technical'  analyses.  Operational  analyses  are  more  of  the  market  research  and 
business  implications.  This  analysis  allows  the  team  to  understand  the  'business  trade  space'  that 
exists.  The  technical  analyses  focus  on  more  than  just  the  technical  implications,  they  also  address  the 
technology  space  (a  trade  space  offered  by  using  different  mixes  of  technology  and  engineering)  for 
tradeoffs. 

Once  these  tradeoff  spaces  have  been  identified  and  explored,  the  last  phase  of  this  process  begins  - 
the  development  of  the  Project  Plan.  During  this  time,  the  formal  business  case  is  developed  as  well 
as  determining  the  single  'solution'  to  pursue  along  with  the  'requirements'  for  that  solution. 

'Boundary  Conditions'  are  part  of  the  detailed  technical  requirements  that  are  developed  during  the 
business  case  development.  These  are  areas  that  are  similar  to  'must-meet'  requirements  or  'minimum 
necessary  conditions'.  They  also  are  able  to  indicate  goals  or  those  features  that  would  be  'nice  to  have' 
within  the  cost,  schedule,  and  other  resource  constraints  the  project  has. 

The  suggested  elements  of  the  business  plan  are  the  description  of  the  technical  proposal;  a  financial 
analysis;  market  and  competitive  strategy;  schedule  and  resource  requirements  for  the  project.  The 
plan  is  usually  about  100  pages  long  (including  the  back-up  technical  pages).  They  put  together  an 
additional  'summary'  (about  5  pages  long)  that  is  used  by  the  decision-makers  for  the  actual  approval 
of  the  project.  Sometimes  projects  look  very  much  the  same  on  paper,  but  in  reality  are  very  different. 
They  have  a  different  focus  and  different  application.  The  team  responsible  for  building  the  business 
case  must  emphasize  the  differences  during  the  approval  process. 
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Upon  the  completion  of  the  business  case,  it  is  presented  to  the  Vice  President  of  the  company 
division.  With  approval,  the  project  moves  into  their  product  development  process.  It  is  a  normal 
practice  for  the  team  members  to  remain  together  for  the  rest  of  the  development  effort  (when  they 
aren't  spending  their  spare  time  pursuing  other  potential  projects). 

The  entire  front-end  process  is  complete  within  approximately  2  months.  This  time  frame  includes 
the  time  spent  in  starting  up  the  team,  getting  them  assigned  to  the  project,  and  actually  doing  the 
work  associated  with  building  the  plan. 

Organizational  Issues 

During  new  produa  development,  the  team  used  to  build  the  business  plan  is  cross-functional  and  the 
members  can  potentially  come  from  any  part  of  the  company.  The  teams  tend  to  be  self-selecting, 
based  upon  employees'  reputation,  and  knowledge  in  a  particular  area.  This  is  another  reason  why 
internal  networks  are  important  to  the  individual  employee. 

Due  to  the  rate  of  change  in  the  industry,  the  full  appreciation  of  technological  change,  engineering 
capabiKties  and  issues  resides  in  the  senior  technical  staff.  Management  tends  to  become 
technologically  obsolete  very  quickly  in  this  environment.  Therefore,  Company  E  favors  its  technical 
staff  over  the  opinions  of  its  management  staff  in  terms  of  produa  requirements  and  the  produa 
features.  Management  simply  determines  the  financial  merits  of  the  projea  and  decides  only  to 
proceed  or  not.  This  requires  the  development  of  tmst  in  the  technical  staff  and  an  individual’s 
integrity  may  often  be  the  deciding  faaor  in  whether  or  not  to  proceed. 

Furthermore,  the  company  will  completely  reorganize  itself  every  3  to  4  years.  This  kind  of 
reorganization  can  be  dramatic.  The  existing  business  units  are  realigned  and  internal  divisions  are 
completely  dissolved.  New  divisions  are  formed  around  the  more  profitable  produa  architectures  and 
employees  are  often  transferred  within  the  new  divisions.  This  is  a  deliberate  strategy  to  keep  the 
company  agile  in  this  industry.  This  is  the  way  the  company  reaas  to  market  changes  vs. 
institutionalizing  a  committee  to  deal  with  the  changes.  It  also  forces  the  development  of  internal 
networks  within  individual  employees. 
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Business  Issues 

The  company  uses  a  3 -year  planning  horizon  to  guide  their  corporate  strategy.  A  longer  timeline  is  not 
realistic  given  the  volatile  environment  of  the  industry.  The  company’s  Research  &  Development 
department  uses  this  horizon  to  develop  a  portfolio  of  potential  solutions  that  then  go  forward  into 
the  other  front-end  processes,  as  discussed  above. 

Another  issue  deals  with  new  technology.  New  technologies  are  rarely  adopted  outside  of  the 
development  organization  (eveiy  department  has  some  kind  of  internal  R&D)  unless  they  have  been 
incorporated  into  a  successful  product  from  that  organization.  This  is  recognized  as  contributing  to 
duplication  of  effort,  proliferation  of  similar,  yet  different,  products  and  to  extending  validation  cycles, 
but  also  enables  very  specific  targeted  products  to  be  developed  quickly  without  a  lot  of  external 
dependencies. 

A  final  issue  is  associated  with  the  costs  of  putting  together  a  business  case.  The  costs  are  usually 
absorbed  by  the  developing  organization  or  associated  project.  The  costs  associated  with  the  front- 
end  are  managed  closely  by  tying  expenditures  to  customer  value  and  perception  of  their  produas.  As 
long  as  the  business  case  development  is  actively  addressing  these  areas,  they  are  given  wide  latitude 
within  the  original  budget.  The  development  costs  are  used  as  a  guideline.  It  is  typical  for  the 
schedule  of  a  project  to  move  fluidly.  A  great  deal  of  effort  is  spent  at  the  finance  manager  level  to 
quickly  identify  opportunities  when  a  project  underspends  and  reallocate  it  during  a  financial  quarter. 
Product/component  costs  are  more  rigorously  managed  due  to  the  greater  potential  impact  on 
revenue  and  profit. 

Summary 

Company  E  has  a  process  that  promotes  flexibility.  The  process  is  built  upon  that  principle.  This 
feature  is  evident  during  the  team  formation  stage,  as  the  team  is  self-selecting.  The  self-selection 
happens  according  to  the  capabilities  of  the  individual  (via  networking  through  the  organization). 
Additionally,  the  source  of  the  ideas  is  bottom-up  driven.  The  culture  of  the  organization  favors  the 
ideas  of  the  technical  employees  over  those  of  management.  This  attitude  could  lead  to  performance- 
driven  products  and  features,  but  the  company  allows  management  to  make  the  project  decisions  on 
the  financial  returns  in  the  business  case.  The  development  teams  are  held  accountable  by 
management  to  stay  within  the  development  budget  requested  as  part  of  the  business  case. 
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Front-End  Process  Flow  Business  Case 


Figure  33.  Company  E's  Front-end  Process  in  Terms  of  the  Framework 

Despite  claims  by  the  company  that  it  lacks  a  formal  process,  a  process  with  many  elements  similar  to 
the  framework  described  earlier  is  present. 

To  its  credit,  the  company  has  one  organization  that  develops  the  idea.  However,  there  is  the  potential 
for  new  products  to  be  created  in  a  vacuum  between  the  different  business  units  of  the  company.  The 
company's  strategy  to  mitigate  this  possibility  is  achieved  through  the  design  of  the  company's  business 
units.  They  are  divided  in  a  way  so  that  they  operate  in  an  exclusive  'area'  within  their  corporate 
framework.  This  means  that  certain  types  of  hardware  and/ or  software  are  only  being  developed  by 
one  organization  of  the  company.  Should  too  much  overlap  occur,  this  is  a  sign  to  the  management  of 
the  company  that  it  is  once  again  the  right  time  for  the  company  to  reorganize.  Nevertheless,  these 
separate  units  must  maintain  close  working  relationships  with  the  other  business  units.  Failure  to  do 
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so  would  result  in  possible  interface  problems  with  the  products  they  offer  (i.e.  software  being  unable 
to  work  on  new  hardware  products  and  so  forth). 

Company  F 

Company  F  is  the  produa  design  and  development  organization  for  an  aerospace  equipment 
manufacturer.  It  is  located  in  the  USA. 

The  company’s  formal  product  development  process  for  the  front-end  consists  of  three  steps  and  one 
review  stage  (or  screen).  The  company  uses  a  common  methodology  for  both  commercial  and 
defense  interests.  Additionally,  technology  development  is  closely  intertwined  with  the  company’s 
front-end  development  process.  The  following  diagram  is  illustrative  of  the  company’s  process  and 
will  be  followed  by  a  discussion  of  its  elements. 


Screening  Conference 


Figure  34.  Company  F's  Front-end  Process 
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As  a  brief  overview  of  the  entire  produa  development  process,  there  are  several  activities  that  take 
place.  Prior  to  their  first  gate  in  their  business  development  process,  is  a  'Create  Business'  pre-process. 
It  consists  of  three  steps  plus  one  screen.  First,  the  company  starts  with  needs  (gathered  from  the 
marketing  department)  and  feedback  from  current  company  products,  and  then  the  company  seeks  to 
develop  opportunities  derived  from  those  sources.  Next,  the  company  will  sort  and  prioritize  the 
opportunities,  then  align  potential  products  and  customer  needs,  and  finally  develop  the  business 
plans.  Upon  approval  of  a  business  plan,  the  formal  product  development  process  begins  and  the 
company  will  acquire  the  required  business  processes,  develop  the  recommended  solutions,  and  finally 
deliver  the  finished  product  to  the  customer. 

Returning  to  the  first  step  in  product  development  for  a  more  detailed  discussion,  the  first  step  is  to 
determine  the  needs  that  exist  in  the  marketplace  and  the  defense  sector.  Marketing  personnel  are 
constantly  gathering  new  ideas.  Those  personnel  gather  ideas  for  the  defense  sector  by  using  concept 
papers  and  attending  wargaming  exercises  to  find  out  what  the  militaiy  believes  is  necessary. 
Additional  sources  for  the  defense  sector  include  information  from  demonstrations;  experiments;  the 
service  laboratories;  Battlelabs,  etc.  Other  sources  can  be  top-down  direaed  as  well  as  originate  from 
employees  of  the  company. 

Marketing  takes  the  information  from  all  of  these  sources  and  thoroughly  analyzes  them  to  get  as  far 
upstream  (or  ahead  in  the  produa  development)  in  the  process  as  possible.  Marketing  integrates 
customer  requirements/needs  across  mission  areas  for  their  defense  customers  and  also  across 
different  markets  for  their  commercial  customers.  They  use  multi-disciplinaiy  IPTs  as  part  of  their 
core  processes.  A  separate  IPT  is  responsible  for  each  'mission  area'  and/ or  marka.  In  the  case  of 
technology  development,  for  example,  one  IPT  will  identify,  prioritize,  and  fund  needed  technologies. 

The  process  for  technology  development  uses  3  sets  of  inputs.  1.  Existing  company  programs,  2. 
Advanced  programs  &  concepts,  3.  Pure  applied  technology  research  programs.  These  constitute  the 
source  of  most  of  the  technology  development  efforts. 

For  a  new  produa  opportunity  to  exist,  the  IPT  evaluates  the  following  faaors:  the  Customer 
Requirement,  if  funding  (by  the  customer)  is  available,  the  current  amount  of  political  support  (for 
military  programs),  and  if  the  required  technology  is  available.  These  criteria  drive  the  answer  of  the 
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metric,  'Potential  to  go',  for  developing  a  technology  or  concept.  It  is  a  qualitative  measure  used  to 
gauge  the  relative  merit  of  a  given  project.  There  are  also  several  enablers  to  ‘Potential  to  go’.  These 
enablers  are  technology  demonstrations  and  studies,  R&D,  test  programs.  Advanced  Technology 
Demonstrators  (ATDs)  and  Advanced  Concept  Technology  Demonstrations  (ACTDs). 

The  second  step  is  to  quantify  the  'performance'  of  the  concept  against  the  'pure'  needs  of  the 
customer.  They  do  this  by  using  the  QFD  process  to  map  the  identified  needs  to  potential  solutions  / 
requirements.  The  solutions  that  come  out  of  the  QFD  process  are  then  ranked  according  to  a  tool, 
called  a  'Customer  Value  Ranking  Tool'  that  tries  to  quantify  the  'utility'  or  'worth'  of  a  solution  to  their 
customer.  They  believe  that  this  step  brings  them  to  at  least  the  80%  solution.  Each  concept  is 
ranked  separately  to  prevent  bias,  and  the  corporate  bottom  line,  company  values,  and  potential  to  win 
are  NOT  considered  at  this  point. 

The  overall  prioritization  scheme  for  judging  the  various  concepts  is  based  on  the  following  criteria. 
The  criteria  seem  to  be  equally  weighted.  The  first  criteria  is  the  Customer  Priority  (in  the  case  of  the 
military,  customer  priority  is  based  on  three  things:  a)  funding  stability,  b)  program  stability  (program 
requirements  and  objects  remaining  stable,  key  personnel  stability  during  the  rrulitaiy  front-end 
development,  etc.),  and  c)  the  importance  (financially)  to  the  company.)  The  second  criteria  is  the 
Merits  of  Business  Case  (i.e.  profit  element,  NPV,  etc.).  The  third  criteria  is  Value  (to  shareholder, 
general  public  /  stockmarket).  The  fourth  criterion  is  the  match  with  Company  Values.  The  last 
criterion  is  a  Potential  to  Win  evaluation.  The  Delphi  Process  was  used  to  determine  the  weights  of 
the  criteria  used  (looking  at  trends  across  successful  programs/ solutions  as  well  as  inputs  from  the 
senior,  more  experienced  employees). 

Time  plays  a  factor  in  these  projerts  as  well.  The  company  will  also  use  the  information 
communicated  by  the  five  criteria  above  to  sort  concepts  along  three  different  time  horizons.  It  is 
important  to  understand  the  importance  of  the  5  pieces  of  data  relative  to  the  different  time  horizons. 
They  use  three  time  horizons:  Near  =  0-3  years;  Mid  =  3  to  10  years;  and  Far  =  10+  years.  Anything 
beyond  15  years  is  considered  too  far  out  to  anticipate  and  plan  for.  Therefore,  in  the  case  of  a  new 
idea  for  a  nulitaty  concept,  the  idea  is  most  likely  to  be  allocated  to  and  sorted  among  either  the  Mld- 
or  Far-  time  horizons.  This  gives  the  company  time  to  further  develop  and  refine  the  concept  for  the 
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company’s  marketing  people  to  use  in  lobbying  the  military  departments  about  the  company’s 
capabilities. 

For  instance,  the  company  uses  a  notional  heuristic  for  judging  when  to  have  a  rmlitaiy  system  concept 
developed.  An  example  case  for  military  system  will  assume  that  from  the  beginning  of  idea 
formation,  it  takes  about  3  years  for  the  political  sponsorship  to  get  to  the  needed  point  for  the 
militaiy  to  initiate  its  Planning  Process.  The  process  then  takes  another  2  years  for  the  Planning 
process  to  verify  that  enough  risk  reduction  has  taken  place  to  reach  acceptable  levels  for  the  military 
to  begin  the  concept’s  development  (i.e.  writing  a  Mission  Need  Statement).  From  this  point,  another 
5  years  can  be  expected  until  the  necessary  funds  are  in  place  to  begin  fuU-blown  development  work 
(approval  and  validation  of  the  initial  ORD). 

Oftentimes,  as  a  customer  develops  the  requirement  for  a  produrt,  the  Concept  of  Operations  is  the 
weakest  part  of  the  customer's  requirements  document.  Most  customers  do  not  know  exactly  how 
they  will  use  a  new  product.  Therefore,  the  company  has  set  up  a  special  group  to  develop  operational 
concepts  further.  This  is  done  just  to  understand  the  requirements  better  (and  marketing  can  use  it  to 
influence  the  customer’s  understanding  of  the  use  of  the  product).  For  instance,  when  the  Air  Force 
does  an  Analysis  of  Alternatives  (AoA),  the  company  will  usually  run  a  'shadow'  AoA  study  (using  the 
company’s  organic  capability). 

During  the  third  step,  the  solutions  are  again  sent  through  the  QFD  process,  but  this  time  the 
solutions  are  scored  against  'Company  values'  and  a  'Potential  to  Win'  criteria.  These  are  the  remaining 
items  from  the  five  criteria  that  had  not  yet  been  considered  during  the  QFD  process.  Different  and 
separate  teams  (from  the  Developing  IPTs)  are  organized  along  mission  areas  and/or  markets  to 
specifically  do  the  second  round  of  QFD  scoring.  They  do  not  take  a  position  of  advocacy  on  any 
concept.  These  teams  are  called  'Joint  Strategy  Teams'.  They  meet  as  required  and  also  at  least  once  a 
quarter. 

This  step  of  the  process  is  where  the  sorting  and  prioritization  takes  place.  However,  it  is  still  too 
difficult  to  build  a  hst  of  prioritized  concepts  ranked  from  top  to  bottom.  Potential  solutions  tied  to 
customer  requirements  are  broken  into  two  'tiers',  Tier  1  and  Tier  2,  along  the  near,  mid-,  and  far  time 
horizons.  Tier  1  includes  those  concepts  that  the  company  believes  are  most  likely  to  succeed.  Tier  2 


157 


are  those  that  are  less  likely  to  succeed.  At  this  point,  the  business  case  for  the  concept  is  built,  usually 
only  for  those  concepts  listed  in  Tier  1. 

Once  the  scoring  is  complete,  the  company  usualfy  assigns  someone  from  the  Joint  Strategy  Team  to 
be  the  'Champion'  of  a  concept.  The  champion  is  someone  that  understands  the  concept  and  is  its 
advocate,  helps  with  the  concept  prioritization  and  defends  the  concept  or  technology  during 
management  reviews. 

When  a  concept’s  business  case  and  its  requirements  are  presented  to  the  screening  function  (called  an 
'Opportunities  Screening  Conference’),  the  concept  champion  is  allowed  to  present  3  or  4 
PowerPoint-type  slides.  One  slide  is  about  the  'Employment  process'  or  how  the  concept  will  be  used, 
and  the  other  slide  is  about  the  'Product/System  Overview'.  The  last  one  or  two  slides  are  about  the 
'Importance  to  the  Customer'  or  the  team’s  interpretation  of  how  important  the  proposed  new 
product  is  to  the  customer  and  the  likelihood  of  the  customer  to  acquire  it. 

The  'Screening  Conference'  occurs  regularly  to  finalize  corporate  strategy  and  approve  business  cases. 
They  usually  meet  quarterly  and  also  get  monthly  reports  on  project  status.  (The  Opportunities 
Screening  Conference  is  a  subset  of  the  Screening  Conference  specifically  called  to  evaluate  business 
cases.)  The  conference  decides  the  actual  strategy  (officially)  just  once  a  year  (as  their  budgeting 
process  is  done  yearly.)  The  conference  looks  at  all  of  the  solutions  from  a  business  unit  perspective. 
They  have  no  advocacy  and  are  independent.  The  members  of  this  conference  are  the  different 
functional  directors  (company  Vice  Presidents  for  those  functions)  and  the  conference  is  chaired  by 
the  company’s  overall  Vice  President.  Each  concept  Champion  presents  information  to  the 
Conference  regarding  the  work  that  has  been  done  to  date  on  a  given  concept  or  presents  the  finalized 
business  case.  Advocating  a  particular  concept  can  be  a  long  process  for  Champions  as  some  of  these 
concepts  are  in  the  Far  Time  Horizon. 

Once  approved  by  the  Screening  Conference,  the  concepts  are  identified  as  'New  Opportunity 
Creations'.  In  praaical  terms,  these  things  don't  yet  exist  in  the  DoD's  Future  Years  Defense  Plan  (2 
to  7  years  away)  or  in  commercial  company’s  strategic  plan.  The  marketing  teams  take  over  after  the 
Conference  has  approved  a  concept’s  business  case.  They  take  the  concept/product  to  the  customer 
and  try  and  sell  it.  (Here  is  also  where  the  relationships  between  the  Air  Force’s  Technical  Planning 
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Integrated  Product  Teams  (TPIPTs)  and  other  military  organizations  (like  Battlelabs)  and  the 
company’s  technical  support  become  more  like  Marketing  aaivities.  In  praaical  terms,  this  activity  is 
most  closely  related  to  the  military’s  planning  functions  that  determine  potential  concepts  for 
capability  deficiencies  or  identified  needs.)  Depending  upon  the  customer's  interest  and  upon 
receiving  any  knowledge  of  a  customer  budgeting  money  to  purchase  such  an  item  determines  any 
further  movement  of  the  approved  concept  and  project  into  the  regular  phase  gate  product 
development  process  this  company  uses. 

Overall,  the  process  is  done  at  the  beginning  of  the  company's  fiscal  year  and  takes  anywhere  from  3 
to  6  months  to  complete  (depending  upon  the  complexity  of  the  concepts  being  debated).  In  1988, 
approximately  140  new  concepts  began  the  process  and  only  about  75  completed  it.  Some  of  the 
concepts  were  combined  with  other  similar  ones  and  others  simply  weren't  able  to  finish. 
Additionally,  no  information  gathered  during  this  process  is  'thrown  away'.  All  of  the  information  is 
stored  and  maintained  in  a  computerized  database  to  avoid  potential  rework,  even  for  those  concepts 
that  didn't  complete  the  process.  The  potential  remains  that  a  concept  could  be  used  in  the  future.  All 
of  the  company’s  IPTs  and  Marketing  personnel  as  well  as  members  of  the  conference  have  access  to 
this  database.  It  is  not  available  to  everyone  in  the  company. 

Orgmvzatiand  Issues 

The  organization  is  matrix-based.  Teams  are  formed  across  mission  areas  and  also  markets  and  draw 
their  members  from  funaional  organizations.  These  teams  mature  ideas  from  'conception'  through 
the  development  of  the  business  plan. 

They  use  an  Excel  database  to  track  technology  development.  They  use  a  much  larger  database  (with  a 
centrally  assigned  number  that  has  the  capability  to  'screen'  for  duplicate  efforts  across  the  other 
business  units,  etc.)  to  store  and  track  their  ideas  and  concept  development  process  for  the  front-end. 

Business  Issues 

They  have  an  annual  budget  process  that  defines  their  resource  allocation  process.  The  process  itself 
only  takes  about  two  months  to  really  get  through.  This  process  occurs  just  prior  to  the  beginning  of 
the  company's  next  fiscal  year.  Ideally,  this  occurs  immediately  after  the  completion  of  the  front-end 
process.  The  Resource  Allocation  Process  is  being  updated  to  reflect  a  more  integrated  approach  to 
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new  product  development.  They  are  stiU  working  on  a  more  thorough  integration  of  strategic 
planning,  product  prioritization,  etc.,  portions  of  resource  allocation. 

Besides  dealing  with  technology  development  specifically  tied  to  current  projects,  about  20%-25%  of 
the  company’s  Internal  R  and  D  (IRAD)  budget  goes  to  applied  technology  research  activities.  The 
IRAD  however,  is  very  oriented  towards  the  Contracted  R  and  D  (CRAD),  which  is  focused  on 
potential  produas.  The  current  mix  is  about  70%/ 30%.  The  topics  for  study  on  the  military  side  fall 
directly  out  of  the  Science  &  Technology  (S&T)  roadmaps.  80%  of  their  IRAD  is  tied  to  an  S&T 
product  or  service.  (Hence  their  ERAD  funding  is  also  directly  tied  to  the  size  of  the  S&T  budget  - 
which  has  been  steadily  decreasing  over  the  past  few  years). 

For  example,  on  the  military  side,  they  map  their  IRAD  projects  directly  against  the  Air  Force’s  Air 
Combat  Command's  (ACC)  top  S&T  deficiencies  (as  found  in  the  ACC  Mission  Area  Plan).  They  are 
also  actively  engaged  with  the  Air  Force  Acquisition  Community  and  Planning  processes  through  the 
TPIPT  process. 

Additionally,  the  company  believes  in  pursuing  certain  technology  developments  even  though  they 
may  not  yet  be  tied  to  a  specific  product  or  technology.  A  portion  of  the  company’s  annual  IRAD 
budget  (approximately  5  - 10%)  is  allocated  to  technology  efforts  that  support  growth  technologies  the 
company  feels  will  be  important  in  the  far-term.  This  portion  of  the  budget  is  prioritized  and  allocated 
through  a  technology  prioritization  process  (separate  from  the  business  development  process 
described  in  this  case  study)  administered  within  the  technical  community  in  the  company.  These  are 
generally  not  yet  associated  with  acknowledged  produas  or  concepts  and  are  usually  high-risk  from  a 
technological  development  standpoint.  It  is  acknowledged  up  front  that  not  all  of  these  will  succeed, 
but  the  overall  effort  will  produce  the  seed  com  for  future  systems  in  the  15-plus  year  time  frame. 

Summary 

Company  F  has  a  robust  front-end  process.  Many  aspeas  of  the  process  mirror  those  advocated  by 
the  framework.  It  is  clearly  tied  to  their  strategic  focus  and  also  their  primary  customers,  although  the 
method  of  gathering  needs  is  different  between  military  customers  and  others,  as  one  might 
presuppose. 
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Figure  35.  Company  F's  Front-end  in  Terms  of  the  Framework 


The  process  uses  a  quantitative  tool  (QFD)  to  bring  rigor  to  the  process  and  uses  clear  criteria  that 
must  be  met  in  order  to  proceed  to  the  next  development  step  or  phase  in  their  process.  One 
advantage  of  this  process  is  that  it  acknowledges  some  concepts  that  are  of  value  to  a  customer  may 
not  be  the  best  ‘value’  to  the  company.  Therefore,  a  mechanism  is  in  place  to  evaluate  and  make 
tradeoffs  in  this  area. 

One  organization  is  responsible  for  the  development  of  new  concepts.  Additionally,  one  team  is 
responsible  for  the  development  of  a  specific  concept  or  concepts.  Furthermore,  a  ‘champion’  is 
dedicated  to  making  sure  the  screening  committee  reviews  the  concept  in  the  best  ‘light’  possible. 
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This  company  takes  a  different  approach  between  the  commercial  and  defense  sectors.  The  sectors 
differ  due  to  the  ‘freshness’  of  the  concepts  that  actually  move  into  their  formal  product  development 
process.  This  means  that  a  ‘defense  oriented  produa’  will  likely  be  pursued  up  to  seven  years  prior  to 
actually  beginning  development  work  on  a  project.  The  commercial  sector  has  a  shorter  delay  time  as 
their  processes  move  faster  than  the  defense  procurement  process.  Therefore,  a  defense-oriented 
concept  can  be  much  more  radical  in  what  it  promises  to  deliver  (in  the  hope  that  technology 
developments  will  enable  the  feasibility  of  the  concept  by  the  time  such  money  becomes  available) 
than  a  commercial  concept  will  be.  Interested  commercial  parties  could  easily  seek  such  a  concept 
soon  after  the  commencement  of  the  company’s  marketing  activities. 

Company  G 

Company  G  is  an  end  user  in  the  airHne  industry.  The  company  is  headquartered  in  the  USA  and 
operates  throughout  the  world. 

The  company  uses  a  process  to  determine  fleet  development  strategy.  The  company’s  front-end  is 
typically  in  the  domain  of  the  marketing  department.  However,  the  company’s  process  has  many 
interesting  traits  and  will  be  discussed  below.  The  following  diagram  shows  the  process. 
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The  Initiative  for  a  new  product  almost  alway^s  comes  from  within  the  Marketing  department. 
However,  new  initiatives  might  come  from  operations,  or  even  finance  depending  upon  the  conditions 
of  the  market,  or  the  conditions  of  the  fleet.  For  example,  marketing  will  try  to  identify  opportunities 
on  how  to  transport  more  or  make  the  decision  to  retire  a  piece  of  equipment. 

There  is  one  formal  step  and  three  screening  committees.  During  the  first  step,  the  marketing 
department  creates  a  proposal.  It  is  then  reviewed  by  the  financial  and  operations  departments. 
According  to  the  company,  the  finance  department  is  usually  the  most  skeptical  and  operations  is  likely 
to  be  the  most  receptive  to  any  new  initiative.  Each  department  has  a  specified  time  period  to  review 
each  proposal.  The  length  of  the  review  period  is  case  specific  -  but  it  is  about  a  month  on  average. 
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The  effort  of  building  the  proposal  begins  by  framing  a  'problem  statement'.  Once  this  problem 
statement  is  determined,  a  market  survey  is  conducted  concerning  the  issue.  The  target  of  the  survey 
is  conditional.  For  a  product  most  likely  to  affect  crewmembers,  the  other  airline  companies  are 
researched  to  determine  their  position.  For  a  product  that  will  directly  impact  its 
customers/ passengers,  market  surveys  using  statistical  sampling  methods  will  be  used,  often  across  the 
different  customer  segments  (business  vs.  pleasure  travelers).  Oftentimes,  the  marketing  department 
doesn't  rely  on  market  research.  The  department  will  use  their  in-house  experts  instead. 

There  are  two  primary  categories  of  product  development  decisions  at  Company  G.  First,  there  is  the 
buying  and/ or  disposing  of  large  capital  equipment.  Second,  there  are  modifications  to  the  capital 
equipment.  (There  is  also  a  third  category  -  other  aircraft  decisions  -  these  go  through  a  much  shorter 
process.) 

With  the  1st  category,  the  company  has  a  5  and  10  year  plan  for  their  domestic  market.  It  is  a  very 
sophisticated  exercise  where  many  factors  are  accounted  for,  including  anticipated  demand  in  a  market 
(plus  the  fare  environment/ traffic  -  impacts  on  revenue),  the  costs  (fixed,  variable,  costs  of  ownership, 
etc.),  the  equipment  types  the  company  has,  and  etc.  From  this  the  company  will  come  up  with  a 
general  plan  like  the  type  of  equipment  with  a  specific  amount  of  capacity  that  is  needed  for  a 
particular  market.  These  plans  are  working  documents.  One  is  called  the  "Fleet  Outlook  Plan". 
Every  two  years,  the  plans  are  redone  primarily  because  the  plans  are  hard  to  do,  and  enough  changes 
have  usually  taken  place  within  the  past  two  years  to  warrant  a  revisit. 

The  2nd  category  is  that  of  modifications  to  the  capital  equipment.  First,  the  company  evaluates  the 
number  of  units  involved  and  figures  out  what  is  required  to  do  the  modification.  The  result  is  a  plan 
on  how  it  win  fit  into  the  normal  checks,  maintenance,  and  schedules  of  the  equipment  in  use. 

Generally  these  kinds  of  modifications  fall  into  two  categories:  mandatory  and  non-mandatory 
changes.  Mandatory  changes  are  usually  those  where  the  customer  doesn't  know  to  care  about  them. 
These  are  usually  changes  that  affect  none  of  the  customer’s  senses  during  the  trip.  They  are  largely 
99%  technical  as  well  (i.e.  government  regulations  &  safety  issues).  These  are  done  as  cost  effectively 
as  possible. 
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Non-mandatoiy  changes  require  rigorous  analysis.  Two  different  departments  usually  do  these  types 
of  modifications:  Technical  Operations  &  Produa  Development.  Both  of  these  departments  are 
customer-focused.  Maintenance  needs  are  usually  done  by  Tech  Ops.  Customer  needs  are  done  by 
Produa  development.  The  focus  of  the  Produa  Development  department  is  on  customer  perception 
issues.  This  usually  boils  down  to  two  types  of  issues:  Competitive  (e.g.  the  company’s  competition  is 
doing  it,  service,  sensory  experiences  of  their  customers,  and  simply  keeping  up  with  the  Jones'.)  and 
non-competitive  ones. 

A  third  category  consists  of  anything  else  that  doesn't  fit  into  the  above  two  categories.  These  consist 
of  usually  small  decisions  less  than  $1  Million  or  taaical  decisions  like  timing  decisions  or  pricing 
decisions  or  price  matching.  These  are  fluid  and  could  not  be  done  through  a  long  process. 

The  previous  two  categories  of  modifications  to  capital  equipment  (mandatory  and  non-mandatory 
changes)  take  approximately  2  months  to  get  ready  for  approval.  The  time  required  to  get  something 
ready  for  approval  is  due  to  the  analysis  process. 

Analysis  is  done  using  the  following:  surv^s,  market  share  reports;  and  using  information  gathered  to 
show  cause  and  effea  relationships.  The  last  step  is  the  most  sophisticated.  The  company  evaluates 
the  proposals  with  the  market  and  the  other  mentioned  faaors  by  using  models  and  simulation.  One 
example  of  this  is  the  company’s  Fleet  Model.  It  addresses  aU  aspeas  of  the  company’s  'Fleet  Outlook 
Plan'.  It  is  a  Mathematical  Integer  Program.  The  plan  takes  two  points  in  time,  5  &  10  years,  as  a 
starting  point.  The  mathematical  program  will  concentrate  on  3  things  given  the  assumptions  and 
constraints  they  have.  The  company  assumes  a  given  schedule  and  tries  to  optimize  the  equipment  on 
a  schedule  that  will  make  the  most  money  and  also  take  into  account  regular  maintenance  and  special 
maintenance  requirements.  The  constraints  are  things  like  maintenance  and  performance  targets.  The 
first  item  is  "Spilled  Revenue."  It  is  a  funaion  of  available  space  -  demand  vs.  capacity  (this  drives 
solution  of  the  program  to  meet  demand  100  %  of  time,  but  this  is  not  optimal.).  The  second  is 
Operational  Costs.  This  drives  the  solution  toward  smaller  equipment  (smaller  the  equipment,  the 
lower  the  costs).  The  third  item  is  'Ownership'.  This  includes  the  cost  of  purchase,  operations, 
maintenance,  etc.  The  objeaive  funaion  of  the  model  is  to  minimize  costs. 
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After  these  models  are  used,  the  marketing  department  will  prepare  the  proposal.  The  proposal  is 
basically  the  business  case.  The  marketing  department  constmcts  it  almost  entire^  themselves.  In 
incremental  decisions,  it  is  pretty  much  a  straightforward  marketing  department  decision.  For  a 
replacement  decision  on  a  fleet-wide  basis,  the  marketing  department  stiU  takes  the  lead  (usually),  but 
there  are  2  or  3  additional  key  factors  in  the  decision.  The  models  are  used  to  help  answer  the 
questions. 

1.  Can  the  company  make  more  money  with  the  new  equipment? 

The  marketing  department  looks  at  the  revenue  produaion  ability  of  the  new  equipment.  These  are 
things  like  range,  capacity,  fuel  efficiency,  etc.).  Will  there  be  increment  revenue  that  will  offset  the 
costs? 

2.  How  much  is  it  worth  to  the  company  -  what  is  the  effect  of  the  public  (potential  customer) 
perception  of  these  products? 

Any  proposal  can  bring  about  many  changes,  some  of  them  unanticipated.  In  essence,  a  ripple  effect 
can  be  created  with  new  equipment  acquisition  that  extends  across  the  entire  fleet.  If  new  equipment 
can  be  placed  on  routes  that  are  'payload  constrained'  such  that  the  new  acquisition  relieves  or  reduces 
that  strain  on  those  particular  routes,  other  equipment  can  be  moved  to  other  routes  to  decrease  the 
constraints  that  exist  on  those  routes.  Hence  the  'ripple'  effect.  TTiis  can  be  very  beneficial,  especially 
on  those  routes  that  are  no  longer  payload  restrirted  because  of  the  new  product. 

The  criteria  used  to  evaluate  all  new  product  proposals  include  'Internal  ROI'  and  'NPV.  NPV 
justifications  are  really  the  bottom  line  vs.  qualitative  reasoning  concerning  any  modification.  The 
company  does  not  track  rejected  proposals.  The  marketing  department  won't  allow  a  proposal  to 
leave  their  department  that  could  be  killed,  so  the  company  has  a  0%  rejection  rate  at  the  concept 
screen.  AH  proposals  must  go  through  the  marketing  department,  even  those  that  do  not  originate  in 
marketing. 

From  this  point,  proposals  enter  the  formal  review  and  approval  process.  Each  committee  has  the 
power  and  ability  to  'turn  back'  a  proposal  or  even  kill  it.  However,  this  almost  never  happens. 
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The  first  review  committee  is  the  Fleet  Committee.  Its  members  consist  of  directors  and  officers  of 
the  company.  It  meets  approximately  once  a  month.  The  second  review  is  a  Finance  Committee. 
Membership  is  similar  to  the  Fleet  Committee.  It  also  meets  approximately  once  a  month.  The  last 
review  is  by  the  Board  of  Directors.  Projects  worth  more  than  $1  Million  go  to  the  Board  for 
approval.  The  Board  membership  consists  of  the  board  of  directors  of  the  company.  The  Board 
meets  at  least  once  a  quarter. 

Organi'zational  Issues 

This  company  has  two  types  of  customers  that  drive  very  different  behaviors.  The  first  type  of 
customer  is  the  employee  within  the  company  that  operates  or  maintains  the  equipment  used  by  the 
company.  There  are  issues  with  new  equipment,  features,  and  retirement  of  existing  equipment  that 
have  to  be  dealt  with  such  as  training  for  familiarity  and  correct  operation.  The  second  type  of 
customer  is  one  who  pays  the  company  for  the  service  of  point  to  point  transportation.  Here  the 
market  is  based  upon  the  senses  of  the  customer  or  the  experience  of  the  customer  while  receiving  the 
service. 

For  this  reason,  the  company  has  two  distina  planning  departments  (fleet  &  market)  whose  needs 
have  to  be  reconciled.  Oddly  enough,  there  are  two  other  departments  (marketing  &  a  'negotiation' 
department  (between  marketing  &  finance))  that  tend  to  act  as  a  'forcing'  function  for  this 
reconciliation  to  occur. 

Business  Issues 

The  Board  of  Directors  mandates  the  goals  and  objectives  of  the  company.  The  company  uses  a  lot  of 
MBO  (Management  by  Objectives)  Planning.  It  provides  an  overall  framework  for  the  coming  year. 
However,  that  list  is  flexible  -  anyone  wanting  to  change  the  list  just  has  to  justify  the  changes.  These 
corporation  objectives  translate  into  the  actions  the  company  will  take  in  the  current  year.  But  at  the 
end  of  the  year,  the  company  has  to  reconcile  the  two  (actions  taken  vs.  what  the  framework 
contained)  -  Bonuses  are  based  upon  this  reconciliation. 

Priorities  are  also  based  on  the  MBOs.  But  these  change.  It  is  therefore  important  to  have  contact 
with  the  senior  management.  Anyone  pursuing  a  new  product  has  to  have  senior  management’s  buy- 
in. 
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AH  plans  they  have  are  taken  care  of  and  updated.  It  is  usually  top-down  directed. 

They  plan  a  budget.  But  they  do  not  execute  the  budget...lt  is  a  plan  only.  It  serves  as  a  benchmark. 
If  an  NPV  analysis  comes  up  with  a  positive  result  for  a  new  concept,  developers  execute  it 
immediately  and  don't  worry  about  it  after  that.  The  finance  or  accounting  departments  end  up 
sorting  things  out.  Nevertheless,  some  departments  are  budget  focused  and  others  are  not.  To 
understand  what  focus  a  department  has,  ask  the  question,  "What  is  the  mission?  What  value  do  they 
add  to  the  company?"  For  example,  an  existing  airport  gate  is  value  focused.  They  need  to  turn  the 
equipment  around  quickly  and  get  it  back  out  on  time. 

Fleet  and/ or  Market  Plarming  is  not  as  focused  on  the  budget.  (They  use  the  budget  mostly  for 
employee  headcount  allocations).  But  because  these  departments  spend  money  to  create  value,  they 
still  have  to  be  aware  of  the  resources  that  are  available. 

Summary 

All  of  the  screens  seem  to  be  in  place  in  order  to  build  consensus  or  organizational  inertia.  This 
judgement  stems  from  the  observation  that  the  marketing  department  won't  let  anything  forward  that 
could  be  killed.  The  marketing  department  is  THE  filter  for  the  front-end  new  product  development 
process. 

New  ideas  come  from  many  areas  and  are  initially  developed  by  multiple  organizations.  The  marketing 
department  takes  all  of  these  ideas  and  removes  any  overlapping  ideas.  The  company  makes  no 
mention  of  cross-funaional  idea  development. 

The  following  diagram  depias  the  company’s  process  in  terms  of  the  idealized  framework. 
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Front-End  Process  Flow  Business  Case 


Figure  37.  Company  G's  Front-end  in  Terms  of  the  Framework 


The  company  shares  some  traits  with  the  proposed  framework,  such  as  conducting  rigorous  analysis 
on  new  product  decisions;  establishing  Criteria  for  the  product  requirements;  and  tying  new  products 
to  the  strategic  plan  of  the  company. 

Company  H 

Company  H  is  an  end  user  in  the  airline  industry.  It  is  headquartered  in  the  USA.  The  company's 
product  development  process  is  well  defined.  It  is  also  distributed.  Items  relating  to  the  operation  of 
the  equipment  wiU  come  from  the  different  funrtional  areas  of  the  company.  The  following  diagram 
outlines  this  process  and  a  discussion  will  follow. 
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Figure  38.  Company  H's  Front-end  Process 


Identification  of  needs  and  suggestions  for  new  solutions  can  come  from  anywhere.  Operations  (& 
training)  is  a  huge  source  of  operator  needs  (and  usually  a  solution  as  well).  As  Operations  &  Training 
or  another  department  tries  to  get  a  need  filled,  that  department  also  might  use  a  few  numbers  in  terms 
of  cost  with  the  department’s  request,  but  these  numbers  are  really  ‘soft’.  The  company  usually  passes 
any  ideas  on  to  whichever  department  deals  with  that  type  of  specialized  equipment  (for  a  first  look). 
The  only  time  things  wouldn’t  come  from  Operations  revolves  around  reliability  issues.  Also, 
Corporate  Programs  translate  the  wishes  of  the  CEO  (top-down  directed  -  “I  want  to  exceed  our 
competition’s  ability  on  the  X  to  Y  route”)  into  requirements  for  new  equipment,  if  necessary. 

The  next  step  in  the  process  is  with  the  financial  department.  The  department  does  an  estimate  on  the 
Total  Ownership  Costs  (TOC)  and  the  revenue  potential  of  the  equipment.  The  estimate  includes 
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things  like  the  lowest  cost  per  mile.  Developing  these  models  is  the  hardest  part  of  the  analysis.  The 
financial  department  has  its  own  studies  group  where  ideas  and  solutions  are  bounced  off  of  the 
models. 

When  comparing  technical  requirements  vs.  finances,  the  financial  department  analysts  usually  rule  the 
day.  It  usually  boils  down  to  the  financing  capabilities  of  the  different  companies  selling  equipment. 
That  feature  has  the  most  impact  on  the  process. 

Resource  planning  personnel  make  the  decisions.  This  department  works  closely  with  the  Financial 
Analysis  group.  The  priorities  for  new  products  are  set  in  a  forum  between  the  two  departments. 
Marketing  personnel  have  a  strong  influence  here  too.  As  technical  requirements  are  analyzed,  the 
company  uses  11  categories  to  prioritize  and  rank.  Mission  capability  is  the  most  important.  The 
other  factors  are  things  like  interior,  maintenance,  technology  state,  and  infrastmcture  capability.  The 
ranking  is  usually  done  using  a  1  to  5  scale.  Subsystems  are  evaluated  more  thoroughly.  The  lowest 
criteria  on  the  list  were  features  for  the  equipment  operators.  Big  changes,  especially  marketing 
changes,  go  all  the  way  to  the  board.  Usually  it  is  a  token  decision.  The  decision  cycle  for  these  kinds 
of  proposals  is  only  2  or  3  weeks. 

The  forum  members  use  ‘Consumer  Reports’  type  of  charts  for  their  senior  management  to  compare 
competing  designs.  The  contrarts  group  in  Finance  put  together  ‘term  sheets’  -  which  are  done  on  a 
contraa  level  and  contain  ratings/ rankings  of  different  manufacturers  and  their  offerings  against  a 
common  baseline.  Sometimes  there  are  up  to  50  items  on  the  sheet  and  are  very  specific  (e.g.  size  of 
the  training  documentation). 

Before  any  item  reaches  the  board  of  directors,  a  policy  board  may  go  through  2  or  3  meetings  (1  per 
week)  to  iterate  the  mix  of  requirements  and  solutions.  Finances  really  drive  the  requirements  of  a 
proposal.  Without  numbers  supporting  the  requirements,  the  company  just  can’t  justify  the 
expenditure  and  the  proposal  is  killed. 

Documents  (for  requirements)  consist  of  letters  to  the  manufacturers  (this  is  outside  of  contractual 
documents).  They  are  logged-in  and  tracked  by  the  manufacturer.  The  company  has  one  person 
dedicated  to  transferring  the  company's  desires  to  the  manufacturer.  Sometimes,  this  person  is  co¬ 
located  at  the  manufacturer's  facility. 
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Coincidental  with  having  a  company  representative  with  the  equipment  manufacturer  is  another  part 
of  the  product  development  process.  It  is  secondary  to  the  main  process  and  can  also  occur 
informally  before  a  contract  is  negotiated  or  signed  with  the  manufacturer.  In  the  context  of  the 
secondary  process,  this  employee  supports  the  main  new  product  development  process  by  ascertaining 
the  capabilities  and  potential  costs  of  a  project  through  consultation  with  the  equipment  manufacturer. 
The  employee  then  feeds  this  information  back  into  the  initial  front-end  development  work.  The 
process  operates  in  the  following  fashion.  The  company  representative  waits  for  letters  or  requests  for 
information  to  come  in  from  a  ‘company  focal  point’.  These  ‘focal  point’  people  number  about  15  or 
20  and  are  known  as  official  ‘requestors’  within  each  of  the  company’s  departments.  If  things  come 
directly  to  the  company  representative  from  the  ‘field’  and  not  from  a  focal  point,  the  request  is 
redirected  back  to  the  appropriate  focal  point  within  the  company.  Requirements  in  this  case  are 
mostly  ‘bottoms-up’.  Often,  the  equipment  manufacturer’s  marketing  department  has  already 
considered  the  needs  of  its  customers  and  the  requested  information  has  already  been  gathered. 
Usually  a  response  can  be  sent  back  to  the  originator  within  24  hours.  Usually  the  information  is  used 
by  the  requesting  department  to  further  pursue  its  product  ideas.  This  will  be  fed  into  the  main  front- 
end  process  from  the  originating  department.  The  information  received  from  the  manufacturer  is 
usually  the  source  of  the  ‘soft’  numbers  that  are  passed  up  with  the  proposal. 

The  company  also  has  a  New  Technology  Engineering  Group.  This  group  acts  as  the  gatekeepers  for 
technology  insertion.  Technology  insertion  is  handled  two  ways.  One  is  outside  ‘rule-making’.  These 
are  decisions  forced  upon  them  by  governments,  etc.,  for  safety  or  other  regulatoiy  changes,  etc.  The 
company  may  lobby  hard  against  some  of  these  changes,  but  once  the  decision  is  made,  the  company 
won’t  fight  the  decision.  However,  the  choice  of  the  supplier  is  not  dictated  so  this  choice  is  usually 
based  on  the  after-sale  support,  as  well  as  being  able  to  meet  the  requirement.  The  second  method  of 
technology  insertion  is  done  on  a  ‘voluntary  basis’.  Voluntary  technology  insertion  is  much  more 
difficult  to  accomplish  or  even  to  succeed  in  getting  a  project  of  this  kind  approved,  as  it  must  be 
justified  to  the  financial  department. 

The  company  does  some  limited  R&D  on  things  like  paint  and  some  highly  specialized  equipment. 
The  company  used  to  have  R&D  in  everything  and  at  one  time  even  had  a  ‘clean  room’  just  for  the 
specialized  equipment.  This  is  no  longer  the  case  as  it  is  now  all  farmed  out.  A  component  shop  is 
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still  aroimd  for  some  organic  maintenance  and  repair,  but  now  most  repair  work  is  sent  directly  back 
to  the  manufacturer. 

Orgmvzatkmd  Issues 

The  overall  makeup  of  the  front-end  is  dispersed.  Every  department  may  participate  in  the  front-end 
if  it  chooses  to  do  so.  However,  the  number  of  people  that  are  known  to  really  identify  needs  and 
requirements  is  a  small  number  of  people.  The  people  in  these  positions  have  been  there  for  a  long 
time.  The  person  who  is  the  contact  with  the  major  equipment  manufacturers  knows  all  of  these 
mdividuals  and  understands  the  process. 

The  development  of  the  company's  strategic  plan  is  often  personality  driven.  The  process  is  not 
usually  repeatable.  It  carries  a  lot  of  biases  (personal  vision  that  seems  to  change  from  year  to  year) 
from  the  person  that  was  tasked  to  write  the  report.  However,  the  process  seems  to  be  repeatable 
when  fleet  replacement/new  purchase  decisions  come  up.  Part  of  this  comes  from  the  rigor 
associated  with  new  acquisitions. 

The  company  is  organized  into  fleets  that  correspond  to  the  different  types  of  equipment  the  company 
operates.  Each  fleet  has  a  Fleet  Captain,  a  standards  person,  and  training  personnel.  These  people  are 
often  the  source  of  many  ideas  and  are  responsible  for  different  things  for  each  fleet.  The  company 
has  learned  that  with  huge  fleet  sizes  of  50  or  more  of  the  same  model,  whole  support  packages  of 
things  like  training,  maintenance,  etc.,  can  be  developed  cost  effectively. 

Business  Issues 

The  company  uses  one  common  heuristic  they  have  learned  over  the  years:  ‘don’t  go  with  the  lowest 
bidder’,  especially  with  developmental  systems. 

The  entire  front-end  process  is  usually  non-stop  and  lasts  about  6  months  until  the  company  actually 
decides  to  sit  down  with  the  manufacturer  and  start  contract  negotiations.  At  this  time,  most  of  the 
specific  technical  requirements  are  already  known  and  not  a  point  of  discussion. 

The  Strategic  Plan  is  written/updated  every  year.  It  looks  out  5  years.  Every  5  years  the  company 
writes  a  Rolling  Fleet  Plan.  It  revolves  around  a  market  forecast  and  population  shifts.  It  addresses 
fleet  mix  and  capabilities,  including  slot  restrictions.  It  is  very  high  level  and  simplistic.  For  example. 
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1999  there  may  be  a  goal  for  so  much  used  capacity  per  trip  to  Hong  Kong  in  aggregate  numbers 
(hundreds  of  tons).  The  fleet  plan  is  shared  with  the  manufacturers.  The  manufacturer  usually  already 
knows  in  advance  what  each  company  in  this  industry  needs.  The  manufacturer  usually  comes  to  the 
company  with  their  ideas  in  similar  areas.  So,  the  overall  effort  for  product  development  seems  to 
dovetail  with  the  manufaaurers'  marketing  efforts.  However,  there  are  other  manufacturers  in  this 
industty  that  usually  aren’t  so  proaaive. 

Summary 

This  company  has  a  formal  front-end  process.  It  shares  many  of  the  same  charaaeristics  of  the 
framework.  The  following  diagram  capmres  this  company’s  process  according  to  the  structure  of  the 
idealized  framework. 
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Figure  39.  Company  H's  Front-end  Process  in  Terms  of  the  Framework 
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One  of  the  distinguishing  charaaeristics  of  their  process  is  the  unique  and  close  relationship  the 
company  has  with  one  of  its  primary  manufacturers. 

T^nother  feature  of  note  is  that  'Resource  Planners'  take  the  lead  in  determining  priorities  for  the 
company.  This  is  done  in  an  integrative  atmosphere  with  participation  of  many  departments,  Finance 
and  Marketing  especially. 

Military  Organizations 

There  are  three  kinds  of  military  organizations  that  are  described  in  the  following  case  studies.  The 
first  case  study  represents  another  nation’s  attempt  at  dealing  with  the  complexities  and  issues  in  the 
front-end  of  product  development.  The  second  represents  the  remaining  three  military  departments 
of  the  United  States.  The  last  type  of  military  organization  described  is  that  of  the  Unified 
Commands,  which  are  made  up  of  end  users. 

French  Procurement  Agency 

The  French  Mditaty’s  way  of  conducting  product  development  is  veiy  similar  to  that  of  the  United 
States.  However,  the  main  differences  between  the  US  model  and  the  French  way  of  doing  produa 
development  are  found  organizationally.  Their  Acquisition  authority,  called  the  Procurement  Agency, 
is  on  the  same  level  as  their  Joint  Chiefs  of  the  different  services.  Support  Functions,  etc.  Each  of 
these  entities  reports  direaly  to  the  Ministry  of  Defense.  The  Procurement  Agency  was  created  in 
1961  and  is  the  source  for  weapon  system  development  for  the  French  military  in  peacetime.  During 
wartime,  product  development  is  shifted  under  the  direction  of  the  Joint  Chiefs.  To  date,  this  has  not 
happened. 

The  overview  of  their  process  is  presented  below.  Detailed  explanations  of  the  different  steps  of  the 
process  are  included  in  the  discussion. 
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Figure  40.  French  Military  Acquisition  System  Front-end  Process 

The  entire  front-end  of  the  French  Military  Produa  Development  Process  is  run  and  managed  by  one 
organization,  the  Force  Systems  and  Futurology  Direaorate  of  the  Procurement  Agency.  The 
Procurement  Agency  has  direa  control  of  nearly  80%  of  the  Defense  Departments  budget,  with  the 
other  20%  used  for  operations  in  the  services.  Additionally,  the  procurement  agency  is  responsible  for 
the  entire  product  development  process  for  the  French  military,  including  the  timing  of  system 
retirement  decisions. 

The  process  begins  with  the  strategic  planning  conducted  by  the  directorate.  The  authors  of  these 
strategic  plans  are  8  Force  VVrchitects  and  a  similar  number  of  Operational  Concept  Officers.  (In  this 
discussion,  the  terms  Architects  and  Directors  coincide  with  Procurement  Agency  personnel  and 
‘officers’  coincide  with  French  Military  personnel.) 
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These  plans  postulate  the  next  30  years  of  threats  and  weapon  system  development.  The  plans  form 
the  framework  of  understanding  for  the  development  of  new  weapon  systems  and  are  the  measure  by 
which  new  product  development  opportunities  are  measured. 

The  Stage  of  Preparation  is  the  first  stage  of  the  process  after  identification  of  deficiencies  and  needs. 
This  stage  contains  a  very  important  screen.  Here,  all  user  needs  are  collected  and  screened  at  this 
stage  by  the  Force  Architeas,  and  the  Officer  in  Charge  of  Weapon  System  Coherence.  This 
committee,  in  close  collaboration  with  the  different  military  force  staffs,  will  determine  possible 
solutions,  clarify  the  mihtary  need  based  on  studies,  determine  the  functions  of  the  new  system,  and 
establish  basic  cost  estimates  of  the  system.  (This  is  analogous  to  a  combined  Mission  Area  Analysis 
and  Mission  Solution  Analysis  done  within  the  US  military.)  Should  these  all  align  with  the  vision 
outlined  in  the  30  year  plan,  and  there  is  money  available  in  the  budget,  given  the  current  existing 
constraints,  the  requirement  moves  into  the  Design  Phase.  The  normal  duration  of  the  preparation 
phase  is  approximately  2  years. 

The  onset  of  the  design  phase  occurs  upon  the  establishment  of  the  Permanent  Integrated  Product 
Team,  lead  by  a  Program  Director  and  also  a  Program  Officer.  The  Program  Director  and  Program 
Officer  are  the  equivalent  of  a  US  Military  1-star  officer.  The  team  consists  of  three  types  of  people. 
The  first  group  of  people  belongs  to  the  Acquisition  Corps  and  come  from  various  functional 
backgrounds.  The  second  group  is  drawn  from  the  different  military  services,  as  required.  The  last 
group  comes  from  industry  (There  are  many  government  owned,  subsidized  companies  in  the  defense 
sector  and  there  are  few  barriers  between  the  Ministry  of  Defense  and  commercial  companies).  The 
team’s  primary  objeaive  is  to  obtain  the  best  relationship  between  cost  and  performance. 

The  Design  Stage  has  two  major  phases.  The  first  is  the  feasibility  stage.  During  this  stage,  the 
requirements  are  analyzed  extensively.  (This  is  analogous  to  the  US  Military’s  Analysis  of  Alternatives 
(AoA).)  Risk  reduction  methods  are  required  and  cost  is  actively  traded  among  the  system 
requirements.  The  output  of  this  stage  is  an  ‘Exploratory  Requirements  Document’.  (This  is  not 
analogous  to  a  MNS  or  an  ORD  in  the  US  Military  -  it  is  closer  to  a  draft  Request  for  Proposal). 

The  Definition  Phase  is  where  detailed  analysis  of  the  requirements  takes  place.  The  loosely  defined 
requirements  from  the  first  stage  of  this  process  are  defined  with  much  greater  rigor.  The  output  of 
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this  stage  is  the  Provisional  Requirements  Document.  This  will  form  the  core  document  around 
which  a  contract  will  be  construaed.  (It  is  very  analogous  to  a  Systems  Requirement  Document  in  a 
US  Mihtaiy  setting.)  Additionally,  the  team  provides  a  set  of  criteria  and  measures  by  which  the 
remaining  product  development  wiQ  be  measured.  These  mostly  consist  of  milestones,  cost,  schedule 
and  performance  data.  The  incentives  for  project  and  organizational  success  are  defined  by  these 
measures.  This  process  normally  takes  between  2  to  4  years. 

At  this  point,  the  program  is  assigned  to  a  new  directorate  within  the  Procurement  Agency.  This  is  the 
Weapons  Systems  Directorate.  The  ‘Programs,  Procurement  Methods,  and  Quality  Directorate’  assists 
them.  Together  these  two  teams  bring  the  proposed  system  into  development  and  later  into 
operation.  As  soon  as  the  system  has  transitioned  to  the  new  directorates,  a  contract  is  awarded  to  a 
contraaor  for  the  remainder  of  the  program  development. 

Issues 

The  process  uses  one  organization  and  one  team  to  steer  the  initial  development  of  the  system.  The 
team  consists  of  permanent  members  who  are  authorized  to  act  in  behalf  of  their  respective 
organizations. 

Additionally,  the  board  of  architeas  and  senior  officers  constitute  the  screening  committee  at  the 
earliest  stages  of  the  process.  The  architeas  maintain  their  connettions  to  the  ongoing  process  due  to 
their  strategic  and  oversight  funaion  within  the  procurement  agency. 

Architeas  and  the  Permanent  Integrated  Produa  Teams  as  well  as  the  introduaion  of  the  Preparation 
Stage  are  the  result  of  a  1997  Procurement  Agency  restmcturing.  The  restmcturing  occurred  to 
comply  with  a  French  Law  requiring  it  to  do  so.  The  Preparation  Stage  was  added  to  put  more 
discipline  into  their  produa  development  process. 

Business  Issues 

The  Restructuring  of  the  Procurement  Agency  was  done  primarily  for  financial  reasons.  The 
restmcturing  was  done  to  reduce  by  30%  the  cost  of  weapon  system  development  programs  during 
the  period  of  1997-2002.  It  also  was  mandated  to  reduce  the  cost  of  government  subsidies  to  the 
defense  industry  by  30%  during  the  same  period.  Finally,  the  law  required  that  the  market  share  of 
foreign  defense  sales  increase  to  approximately  15%  of  the  world  market. 
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Finances  for  the  defense  department  are  funded  over  a  five-year  period  by  the  French  government.  It 
is  the  responsibility  of  the  Ministry  of  Defense  to  ensure  that  the  various  departments  within  the 
ministry,  including  the  Procurement  Agency,  manage  those  resources  wisely. 

Summary 

Overall,  the  process  contains  many  elements  of  the  idealized  framework.  The  procurement  agency  can 
be  compared  to  a  large  company  that  begins  its  process  by  listening  to  the  user.  One  of  the  overall 
differences  in  this  process  is  that  the  user  has  representation  on  all  of  the  product  development  teams 
as  well  as  the  initial  screening  committee. 


Front-End  Process  Flow 


Business  Case 


Figure  41,  French  Front-end  Process  in  Terms  of  the  Framework 
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Upon  the  completion  of  the  front-end  process  and  during  transition  to  the  other  two  process  owners 
downstream,  a  true  Business  Case  is  presented.  The  results  of  the  detailed  requirements  analysis  along 
with  the  other  studies  conducted  contain  all  of  the  information  to  complete  the  business  case.  Should 
all  the  risks  be  in  appropriate  ranges,  as  set  by  the  initial  committee,  the  other  direaorates  immediately 
launch  contract  negotiations  with  the  appropriate  defense  contractor.  However,  the  actual  business 
decision  to  pursue  development  of  a  weapon  system  takes  place  with  the  decision  of  the  Stage  of 
Preparation  Committee  (during  the  stage  of  their  process  that  is  most  analogous  with  the  Initial 
Screening  phase  of  the  idealized  framework).  Since  the  Force  Architects,  who  are  members  of  the 
committee,  are  also  core  personnel  within  the  Force  Systems  and  Futurology  Directorate,  the)^  have 
oversight  into  the  overall  process.  Should  instances  arise  that  warrants  kiUing  a  program  before  leaving 
the  oversight  of  the  directorate,  the  Force  Architects  have  the  power  to  do  so  in  conjunction  with 
Operational  Concept  Officers. 

The  activities  corresponding  to  the  Concept  Development  phase  of  the  idealized  framework  suggest 
much  closer  working  relationships  between  the  acquisition  personnel  and  defense  contractors  than 
exist  in  US  Military  relationships.  The  Identification  and  Initial  Screening  activities  are  closest  to 
existing  practice  within  the  US  Military. 

US  Military  Services 

The  Three  US  Militaiy  Services  are  presented  below  in  separate  case  studies  focusing  on  their 
respective  front-end  processes. 

Navy  Front-end  Process 

The  Navy  has  a  veiy  centralized  process  for  weapon  system  development.  The  following  diagram 
illustrates  the  overall  process  of  the  Navy’s  front-end. 
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Figure  42.  Diagram  of  the  Navy’s  overall  front-end  process 

The  Navy  does  not  have  a  formalized  Strategy  to  Task  environment  or  anything  similar  to  the  Air 
Force’s  Modernization  Planning  Process.  However,  the  Navy  does  use  strategy-to-task,  task-to-need, 
and  need-to-solution  as  the  process  of  choice.  The  Navy  also  states  that  the  first  choice  to  solve  a 
deficiency  is  to  do  so  through  a  non-materiel  solution  -  mostly  for  the  lower  costs  involved  through 
such  a  resolution.  If  none  exists,  then  a  materiel  solution  is  sought.  However,  according  to  N8,  the 
greatest  source  of  deficiencies  for  materiel  solutions  comes  not  from  the  Navy’s  formalized  planning 
process,  rather,  the  front-end  product  development  process  relies  upon  any  source  willing  to  identify  a 
deficiency  and  exert  the  effort  to  document  it.  Sources  of  deficiencies  can  either  be  top-down  or 
bottom-up  generated.  Examples  of  this  include  exercise  debriefs,  studies  where  the  Chief  of  Naval 
Operations  provides  an  input  during  the  ‘out-brief,  ACIDs,  lab  efforts,  inputs  from  the  “smart 
people”  in  the  field,  and  any  other  external  source  (fleets,  another  sponsor,  other  services,  etc.) 
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Therefore,  the  process  really  begins  when  someone  or  some  organization  sends  in  a  written 
description  of  a  deficiency.  This  can  be  in  the  form  of  a  Mission  Needs  Statement  draft  (the  format 
and  regulations  are  public  documents,  so  any  naval  personnel  can  read  and  follow  the  format),  or 
another  written  document. 

These  documents  are  sent  in  to  N8''^,  the  Navy’s  Deputy  Chief  of  Naval  Operations  Resources, 
Warfare  Requirements  and  Assessments  division.  N83  is  the  CINC  Liaison  Division  and  collects  the 
documents  from  the  fleet.  N8  plays  a  crucial  role  in  the  Navy’s  product  development  process.  It 
controls  50%  of  the  Navy  Staff  in  the  Washington  DC  area  and  approximately  75%  of  the  Navy’s 
Total  Obligation  Authority. 

N81,  the  Assessment  Division,  conducts  a  ‘screen’  on  the  deficiency  to  see  if  it  passes  the  need  ‘sanity 
check.’  The  overall  criteria  for  this  screen  are  based  upon  the  expert  judgement  of  the  N81  staff.  If 
the  deficiency  is  judged  worthy,  N81  will  distribute  the  proposal  to  the  various  N8  divisions  (and  sub 
elements)  to  seek  a  program  sponsor.  This  is  an  implicit  second  screening  that  takes  place.  Each 
division  as  a  part  of  N8  has  their  own  budget  and  knows  its  resource  constraints  as  well  as  a  general 
sense  if  the  deficiency  ‘fits’  in  with  their  overall  objeaives  for  their  division.  If  a  sponsor  doesn’t  pick 
up  the  deficiency,  the  initiative  dies  (the  deficiency  doesn’t  go  away  -  there  just  isn’t  enough  interest 
within  the  different  agencies  to  pursue  its  resolution  (at  that  time).) 

If  an  organization  decides  to  pursue  a  deficiency,  that  organization  becomes  the  sponsor.  The  sponsor 
then  becomes  responsible  for  all  of  the  document  generation  and  staffing  as  well  as  for  the  financial 
support.  The  sponsoring  organization  tasks  an  action  officer  with  the  deficiency.  That  Action  Officer 
is  then  responsible  for  the  writing  of  the  Mission  Needs  Statement  (MNS),  guiding  it  through  the 
validation  and  approval  stage.  If  approved,  the  action  officer  is  given  money  by  the  sponsoring 
organization  to  do  an  Analysis  of  Alternatives.  The  overall  process  to  get  approval  for  a  MNS  is 
approximately  6  months. 


N8  has  10  sub-elements  (and  these  each  have  several  sub-elements  within  them).  N80  is  the  Programming  (comptroller)  Division.  N81  is  the 
Assessment  (Analysis)  Division.  N82  is  the  Fiscal  Management  Division,  N83  is  the  CINC  Liaison  Division.  N84  is  Anti-Submarine  Division.  N85  is 
the  Expeditionary  Warfare  Division.  N86  is  the  Surface  Warfare  Division.  N87  is  the  Submarine  Warfare  Division.  N88  is  the  Air  Warfare  Division. 
N89  is  the  Special  Programs  Division. 


182 


An  independent  analysis  group  conducts  the  Analysis  of  Alternatives  (AoA).  The  overall  responsibility 
for  the  AoA,  although  the  sponsor  is  paying  for  it,  is  given  to  the  respective  Program  Element  Officer, 
or  other  Naval  command,  to  ensure  the  independent  analysis.  The  AoAs  have  lengths  of  variable 
duration.  They  can  last  a  couple  of  weeks  or  as  long  as  2  years. 


MS  0  MSI 


Figure  43.  Diagram  of  the  Activities  of  the  Navy’s  front-end  process 

As  the  AoA  is  being  conducted,  the  Action  Officer  begins  writing  the  ORD.  Pending  the  results  of 
the  AoA,  which  is  the  foundation  for  the  KPPs  and  other  threshold  and  objeaive  requirements  listed 
in  the  ORD,  the  ORD  validation  and  approval  process  begins.  The  ORD  is  staffed  throughout  the 
Navy  for  review  (the  longer  the  AoA,  the  more  organizations  that  request  a  review  of  the  ORD). 
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The  ORD  has  an  initial  review  cycle  outside  of  the  sponsoring  organization  (which  undoubtedly  has  its 
own  internal  review).  The  cycle  has  been  formally  diagramed.  An  example  is  found  below.  There  are 
slightly  different  variations  to  this  process  depending  upon  the  importance  and  complexity  of  the 
project. 


Figure  44.  Diagram  of  the  Navy’s  approval  process  for  needs  and 

requirements 


Once  the  ORD  has  been  approved,  the  funding  process  begins.  While  this  is  not  necessarily  done  in  a 
serial  fashion,  it  will  be  depicted  in  this  manner  for  simplicity.  The  sponsor  takes  the  ORD  and 
discusses  the  issue  of  funding  with  N80.  The  sponsor  and  also  N80  will  then  both  go  to  N8  and 
recommend  that  the  program  be  started.  It  must  be  fully  funded  for  the  program  to  begin  per  federal 
law,  (but  a  liberal  interpretation  of  the  law  means  the  program  is  fully  funded  if  the  sponsor 
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demonstrates  they  are  willing  to  stand  up  for  the  program  and  put  it  into  the  POM.)  N-8  then 
approves  the  program  to  go  to  a  Program  Element  Officer  and  for  acquisition  activities  to  begin. 

Orgmiiatim  Issues 

The  Navy  has  one  'process'  owner,  N8,  for  their  Requirements  development.  However,  the  actual 
work  is  done  by  one  of  many  sponsoring  organizations  within  N8.  N8  also  controls  most  of  the 
Navy's  obligation  authority  and  funds  for  product  development,  as  mentioned  earlier.  For  this  reason, 
different  N8  sub-processes  control  resources  (and  a  budget)  along  with  Requirements  development. 
Nevertheless,  another  organization,  the  Assistant  Secretary  of  the  Navy,  Financial  Management  & 
QrmptroUer  division,  is  responsible  for  building  the  Navy's  POM  and  budget. 

The  use  of  an  Action  Officer  to  shepherd  a  need  or  deficiency  or  requirement  through  the  entire 
process  is  a  variation  on  the  'core  team'  idea.  In  this  case,  the  sponsoring  organization  can  serve  as 
periphery  team  members  and  the  Aaion  Officer  is  the  'team'. 

Business  Issues 

Prioritization  of  needs  and  requirements  is  done  at  the  sponsor  level.  They  decide  which  need  or 
requirement  to  pursue  when  they  decide  to  write  the  MNS  or  the  ORD.  Oftentimes,  a  committee 
does  this  prioritization  of  needs  and  requirements.  The  committee  consists  of  both  'fleet' 
representatives  and  N8  members.  In  the  case  of  Aviation,  N88,  this  group  is  known  as  the  Air  Board. 
Its  members  consist  of  Navy  Captain  (0-6  rank)  members  from  the  fleet  who  are  senior  aviators, 
members  of  the  Naval  Aviation  Logistics  Group  and  N88  members.  This  06  level  is  where  the  trades 
between  requirements  and  resources  are  made. 

N8  uses  an  Information  Technology  tool  called  Link  for  their  Requirements  documents,  Requirements 
traceability,  and  Requirements  management.  It  is  another  type  of  requirements  management  tool  that 
can  be  easily  integrated  into  the  Microsoft  Office  suite.  It  also  uses  a  database  built  upon  Microsoft 
Access  to  track  projects.  This  tool  is  fully  functional  with  the  Access  program. 

This  liberal  interpretation  of  the  funding  issue  allows  sponsoring  organizations  much  more  flexibility 
in  their  program  execution.  However,  it  opens  them  up  to  the  problem  of  starting  up  a  lot  of 
programs  and  then  not  having  the  resources  available  to  finish  them. 
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Stmvrwy 

Overall  the  Navy  addresses  each  of  the  different  stages  of  the  framework  with  their  process. 
However,  their  process  does  have  some  unique  elements  that  are  worth  highlighting. 


Front-End  Process  Flow 


Business  Case 


Figure  45.  The  Navy's  Front-end  Process  in  Terms  of  the  Framework 

The  Navy  process  contains  multiple  screens  -  beyond  those  mandated  by  the  process  instructions  of 
the  Joint  community.  The  reasons  for  this  are  not  clear  but  the  additional  screens  may  be  done 
because  most  of  the  resources  required  for  a  program  are  also  controlled  by  the  same  organization. 
Another  reason  for  the  screens  may  be  due  to  the  distinct  lack  of  end  user  interaction  with  the  process 
beyond  the  initial  deficiency  identification. 
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The  use  of  Action  Officers  throughout  the  process  is  a  highlight  of  the  process.  Although  an  Action 
Officer  is  a  team  of  one,  it  does  not  benefit  from  the  idealized  framework  team  composition.  Among 
the  key  elements  missing  are  cross-funaionality  and  multiple  perspectives.  Aaion  Officers  become 
the  champions  of  projects  even  within  the  sponsoring  organization  and  they  are  responsible  for  seeing 
each  project  through  the  system  until  that  project  is  started  with  a  favorable  Milestone  I  decision. 
However,  it  is  not  known  what  happens  during  personnel  rotation  in  and  out  of  the  N8  organization 
and  what  effect  this  might  have  on  the  stams  of  a  project. 

The  overall  time  required  to  navigate  the  system  did  not  seem  to  be  significantly  different  from  the 
other  mUitaiy  processes  examined,  except  that  the  Mission  Need  Statement  approval  cycle  time  was 
about  six  months  (180  days)  vs.  the  longer  process  of  about  400  days  in  the  Air  Force. 

Army  process 

The  ARMY  has  a  formal  front-end  process  for  weapon  system  development.  It  is  a  distributed  system 
spread  out  between  31  ‘schools’  (organizations  that  develop  doctrine  and  tactics  for  specific  missions 
of  the  Army)'*^.  Each  school  has  approximately  25  to  50  people  working  on  the  front-end  concept 
development  at  any  given  time.  The  Training  and  Doarine  Command  (TRADOC)  is  the  command 
responsible  for  Force  Development  Requirements  Determination.  TRADC>C  has  not  only  the  combat 
developments  mission,  but  also  runs  the  individual  training  mission.  TRADC)C  manages  the  major 
Army  installations  in  the  United  States  housing  Army  training  centers  and  Army  branch  schools. 

Author’s  Note:  The  Army  has  expressed  it  is  not  satisfied  with  the  way  their  Requirements  Process  is 
working.  They  started  an  effort  in  late  1999  to  reexamine  the  way  th^  develop  requirements.  At  this 
time  there  is  no  indication  about  what  changes  if  any  will  be  made  to  the  process.  Some  of  their 
concerns  are  that  the  decentralized  nature  of  the  system  is  perceived  to  be  ‘bad’,  the  process  is 
currently  not  ‘user-friendly’,  and  the  current  system  seems  to  be  too  ‘stovepiped’  given  the  stracture  of 
the  schools. 


Air  Defense  ArtiBeiy  School,  Adjutant  General  School,  Amior  School,  Amy  Management  Staff  College,  Aviation  Logistics  School, 
Aviation  School,  Chaplain  School,  Chemical  School,  Command  and  General  Staff  College,  Defense  Language  Institute  Foreign 
Language  Center,  Engineer  School,  Field  Artifleiy  School,  Finance  School,  Infantry  School,  Intelligence  School,  Logistics  Management 
College,  Mihtaiy  Police  School,  Ordnance  Missile  and  Munitions  School,  Ordnance  School,  Quartermaster  School,  School  of  the 
Americas,  School  of  Music,  Sergeants  Major  Academy,  Signal  School,  Soldier  Support  Institute,  Transportation  School,  Warrant 
Officer  Career  Center 
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The  following  diagrams  show  the  various  aspects  of  the  front-end  of  the  Army.  In  essence,  aU 
requirements  are  generated  at  a  decentralized  level  and  then  fed  back  up  to  TRADCXl.  From  this 
point,  the  process  of  MNSs  and  ORDs  follows  the  standard  DoD  procedures. 


Deficiencies  are 
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Figure  46.  The  overall  needs  and  requirements  process  in  the  Army  from 

an  organizational  standpoint 

The  overall  process  operates  in  a  fashion  usually  as  described  above.  The  Army  Staff  at  Army 
Headquarters  conducts  a  screening  event  before  TRADOC  gets  involved.  This  ensures  that 
TRADOC  stays  focused  on  the  Army’s  mission  in  its  concept  development  activities.  Activities  such 
as  technology-push  from  labs  and  other  sources  get  their  first  opportunity  to  influence  product 
development  only  at  the  TRADOC  level. 
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Figure  47,  Development  of  Needs  and  Requirements  in  the  Army 
(Adapted  from  TRADOCPam  71-9,  Figure  9-1) 

The  material  developer  in  the  diagram  above  is  the  acquisition  community  that  is  kept  aware  of 
developments  during  pre-milestone  0.  The  combat/training  developer  shown  above  is  the  TRADOC 
School  charged  with  understanding  the  need. 

An  Integrated  Concept  Team  (ICT)  is  the  Army  management  philosophy  and  tool  for  a  team 
approach  to  requirements  generation.  It  is  a  mvJti-disciplinary  team  that  is  in  charge  of  the 
development  of  user  needs  and  requirements  into  products  such  as  a  Mission  Need  Statement  and  an 
Operational  Requirements  Document.  Team  members  are  empowered  to  make  decisions  on  behalf  of 
the  organi2ations  that  they  represent.  This  same  team  consists  of  a  core  group  of  individuals  who  are 
assisted  by  periphery  members  as  required.  The  ICT  is  responsible  for  the  entire  process  through 
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Milestone  1.  As  the  process  prepares  to  enter  the  acquisition  community,  the  ICT  is  assisted  by  a 
companion  Integrated  Product  Team  (EPT)  that  assumes  more  and  more  responsibility  as  the  process 
for  a  material  solution  goes  forward  until  the  IPT  assumes  full  control  just  after  Milestone  I  in  the 
acquisition  process.  There  are  approximately  40  ICTs  going  on  at  any  given  time. 

The  ICT  is  charged  to  pursue  Horizontal  Requirements  Integration  (HRI)  in  the  development  of 
mission  needs  and  requirements.  HRI  is  a  holistic  process  that  attempts  to  develop  requirements  that 
encompass  the  entire  ‘force’,  not  just  a  particular  domain  (like  tank  warfare).  To  this  end,  there  are 
two  types  of  ICTs.  Tier  1  ICTs  are  approved  and  chartered  by  TRADOC  HQ  or  impact  multiple 
schools  or  have  a  high  management  interest.  Tier  2  ICTs  are  established  and  run  by  the  school 
commandants.  They  look  at  requirements  that  have  no  Impact  beyond  the  domain  of  the  school. 
HRI  is  not  limited  to  only  materiel  solutions. 

The  DTLOMS  (Doctrine,  Training  Leadership,  Organizations,  Materiel,  and  Soldier)  structure  is  the 
method  by  which  the  ICT  evaluates  a  mission  need.  The  structure  of  DTLOMS  inpHes  a  hierarchy  of 
importance,  as  well  as  one  related  to  the  amount  of  resources  required  to  implement.  The  further  a 
solution  'goes'  along  the  DTLOMS  axis  towards  ‘Soldier’,  the  more  expensive  it  is  to  correct  the 
mission  deficiency  and  implement  a  solution.  Furthermore,  such  a  solution  always  has  repercussions 
back  up  the  axis  as  it  impacts  everything,  including  doctrine.  Additionally,  the  ICT  must  develop 
solution  ‘sets’  that  include  near-,  mid-,  and  long-term  capabilities  for  each  mission  need.  Money  for 
the  studies  and  analysis  to  develop  mission  needs  and  requirements  comes  out  of  the  Army’s 
Operations  and  Maintenance  fund.  Most  studies  and  analysis  require  1  to  2  years  prior  to  beginning 
writing  requirements  documents  such  as  an  Operational  Requirement  Document. 

The  approval  process  for  these  items  follows  the  path  indicated  below. 
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Figure  48.  Validation  and  Approval  process  in  the  Army 

Any  time  an  ICT  develops  material  requirements  that  will  begin  the  Army’s  product  development 
process,  the  ICT  will  draft  the  document.  The  School’s  leadership  must  first  approve  the  document, 
and  then  the  document  is  sent  to  HQ  TRADOC.  At  the  HQ,  the  document  is  compared  and 
‘harmonized’  with  any  other  documents  produced  by  other  ICTs  from  other  schools.  This  means  that 
overlapping  requirements  are  combined,  conflias  in  mission  areas  and  roles  are  resolved,  and  only  one 
requirement  in  a  given  area  is  allowed  to  proceed.  When  this  is  completed  and  the  document  is 
approved  by  the  TRADOC  commander,  the  document  is  coordinated  for  review  at  the  Army  Staff 
level  in  Washington  DC  before  going  to  the  Army  Chief  of  Staff.  If  the  program  requires  the  approval 
of  the  JROC,  the  document  then  enters  a  separate  process  of  staffing  and  review  in  the  joint 
environment  prior  to  the  document’s  approval.  Mission  Needs  Statements  require  approximately  six 


months  from  the  start  of  the  review  process  to  the  final  approval.  Operational  Requirements 
Documents  require  approximately  six  months  to  one  year  to  go  through  the  approval  process. 

The  ICT  works  on  the  development  of  the  need  and  requirement  stemming  from  the  deficiency.  The 
core  team  remains  intact  and  during  the  review  and  approval  processes  for  both  the  MNS  and  the 
ORD,  so  that  the  team  can  respond  direaly  to  issues  that  are  raised  during  the  process.  They  also  are 
responsible  for  the  development  of  the  need  and  requirement  through  studies  and  analysis.  Because 
of  this,  the  ICT  is  well  equipped  to  field  questions  during  the  approval  process. 

The  last  part  of  the  process  is  the  way  product  development  projects  are  funded.  Funding  decisions 
are  done  through  an  entirely  different  process.  This  process  is  essentially  the  same  as  the  Air  Force 
funding  process,  which  was  explained  earlier.  The  method  by  which  the  Army  Requirements 
Developers  influence  the  process  is  called  the  Warfighting  Lens  Analysis  (WFLA).  This  is  the  way 
TRADOC  shows  advocacy  for  a  program.  Using  a  methodology  similar  to  a  Linear  Program,  the 
methodology  attempts  to  prioritize  investment  decisions  for  the  Army.  The  WFLA  compares  the 
required  future  capabilities  of  the  Army  Total  Force  against  the  current  fiscal  reality.  This  is  used  to 
determine  modernization  priorities  from  the  point  of  view  of  TRADCC.  These  priorities  are 
established  using  a  methodology  that  assigns  an  objective  measure  of  relative  value  to  the  mission 
accomplishment.  TRADOC  provides  WFLA  recommendations  to  Army  HQ  as  key  input  for  the 
POM  (December-odd  year)  development  and,  if  needed,  for  the  mini-POM  (December-even  year) 
development.  This  process  begins  approximately  one  year  prior  to  the  PPBS  cycle  that  will  build  the 
POM  in  question.  The  WFLA  process  has  the  potential  to  change  its  outcome  and  priorities  every 
year  the  analysis  is  done.  Should  this  occur,  the  process  relies  upon  the  judgement  of  the  decision¬ 
makers  in  this  process  to  note  the  discrepancies  and  react  accordingly. 
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Figure  49.  Notional  time  required  navigating  the  process  for  needs  and 

requirements  in  the  Army 

This  diagram  shows  that  if  the  overall  front-end  product  development  process  worked  perfectly  and 
that  those  average  process  times  accompanied  a  deficiency/need/requirement,  the  process  requires  six 
years  for  a  program  start  to  occur.  The  difficulty  in  describing  these  processes  serially  is  that  they  are 
constantly  changing.  This  representation  implies  perfect  handoffs  between  TRADOC  and  perfectly 
getting  program  requirements  into  the  POM  process.  The  diagram  also  assumes  that  the  first  time  a 
MNS  is  approved  that  it  will  make  it  into  the  next  POM.  The  diagram  also  assumes  there  are  no 
politically  charged  issues  with  the  requirement  that  might  delay  the  process  outcome.  This  does  not 
always  occur.  Intuitively,  if  some  of  the  firm  dates  to  participate  in  the  resourcing  process  are  missed, 
another  year  is  potentially  added  to  the  process.  It  is  also  clear  that  delays  in  any  of  the  processes 
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invariably  lengthen  an  already  long  front-end  process.  Additionally,  this  process  flow  is  very 
complicated  in  that  it  is  continuous.  For  instance,  this  diagram  really  should  contain  the  overlapping 
processes  of  the  six  years  worth  of  POM  building  that  would  occur  on  this  time  line. 

The  various  Army  Commands  are  not  prohibited  from  developing  concepts  and  ideas  on  their  own 
and  to  field  and  deploy  them.  However,  should  a  decision  to  do  so  be  reached,  that  Major  Command 
is  then  obligated  to  be  responsible  for  all  training,  education,  doctrine,  maintenance,  and  support  of 
that  equipment.  Because  of  these  reasons,  this  approach  is  rarely  used. 

According  to  the  Army,  within  the  'normal'  system,  there  is  a  pervasive  atmosphere  today  of  not 
spending  money  on  a  program  unless  the  Army  is  absolutely  sure  that  it  is  worth  it.  Therefore,  a  lot 
more  analysis  and  experimentation  is  done  than  ever  before. 

There  are  other  processes  that  exist  to  ‘shorten’  the  process  or  take  advantage  of  new  technologies, 
etc.  These  are  funded  under  special  programs  like  the  WRAP  (W arfighter  Rapid  Acquisition  Program) 
of  the  Soldier  Enhancement  Program.  Most  of  the  shortening  that  occurs  is  only  in  the  review  and 
prioritization  processes  -  not  the  analyses  or  other  background  work  the  ICT  normally  does. 

Orgamiational  Issues 

The  Army  Requirements  Process  could  be  compared  to  an  hourglass.  At  the  top  level,  items  for 
discussion  can  come  in  from  anywhere.  They  all  must  go  through  the  Army  HQ  Staff  and  TRADCXi; 
and  then  TRADCXH  distributes  all  of  the  work  out  through  the  3 1  schools  it  operates.  Then,  as  the 
ICTs  converge  on  a  ‘solution’,  then  they  must  go  again  through  TRADOC  (the  neck  of  the  hourglass) 
and  then  go  up  to  the  Army  staff  and  are  distributed  throughout  the  Pentagon  and  Joint  community 
for  further  vaKdation  and  approval  actions. 

The  ICT  is  a  unique  expression  of  a  military  team  developing  requirements  from  the  initial  part  of  the 
fuzzy  front-end  of  the  process  all  the  way  through  Milestone  I,  where  it  is  transitioned  to  an  IPT  of 
acquisition  professionals.  Organizationally,  the  ICT  makes  binding  decisions  for  the  Army 
organizations  they  represent,  although  they  are  operated  within  the  schools  of  TRADOC. 
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Business  Issues 

The  use  of  the  DTLOMS  method  in  defining  deficiencies  and  developing  needs  and  requirements 
from  them  comprises  an  integrated  look  at  all  of  the  components  of  the  ‘business’  of  the  Army. 
Strategically,  this  method  is  critical  so  that  the  focus  of  product  development  within  the  Army  remains 
tuned  to  the  roles  and  mission  of  the  Army. 

Like  the  Air  Force,  the  Army  has  a  separate  method  to  allocate  and  prioritize  resources.  This  system  is 
veiy  formalized  and  requires  a  lot  of  effort  to  obtain  the  desired  outcome  -  funding  the  needs  of  the 
Army.  The  business  case  for  potential  product  development  projects  is  constmcted  by  the  ICT  and 
documented  in  the  MNS  and  ORD.  However,  there  is  no  organization  within  the  Armythat  approves 
a  ‘business  case’.  These  are  split  into  two  separate  actions  -  the  Army  Requirements  Approval  Process 
and  the  WFLA  process.  The  ICT  only  submits  information  to  the  WFLA  process.  The  ICT  does  not 
control  it  nor  maintain  it  (however,  the  WFLA  process  is  owned  by  an  organization  within 
TRADOC). 

Stmmary 

The  Army  process  contains  several  elements  of  the  idealized  framework.  Among  the  more  interesting 
items  is  the  existence  of  the  ICT,  the  holistic  look  of  how  a  need  or  deficiency  fits  into  the  strategic 
aims  of  the  organization  (the  Army)  and  the  use  of  quantitative  tools  to  develop  a  prioritized  list  of 
requirements.  Also  of  note  is  the  sophisticated  use  of  modeling  and  simulation  at  this  early  stage. 
Additionally,  allowing  the  ICT  to  determine  which  type  of  development  path  a  need  or  requirement 
should  take  (i.e.  ATD,  ACTD,  Experiments,  and  Battlelabs)  shows  remarkable  trust  in  the  ICT 
process. 
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Nevertheless,  a  review  of  the  process  in  light  of  the  idealized  framework  seems  to  indicate  a  lack  of 
trust  among  the  different  organizations  (each  one  needing  to  coordinate  and  validate  the  work  of  the 
ICT  before  releasing  it  to  the  next  higher  organizational  level  within  the  Army).  This  becomes  a 
process  of  “checkers  checking  the  work  of  the  checkers.”  Furthermore,  the  process  seems 
disconnected  between  the  development  of  needs  and  requirements  and  the  budgeting  and  funding  of 
those  needs  and  requirements.  It  is  not  clear  that  the  process  is  integrated  between  these  items. 

Marine  Corps  process 

The  Marine  Corps  has  a  formalized  front-end  process  as  a  part  of  its  product  development  process. 
Its  focus  is  to  produce  integrated  capabilities  for  the  Marine  Corps.  The  Marine  Corps  Combat 
Development  Command  (MCCDC)  is  responsible  for  the  process.  The  Commanding  General  of  the 
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MCCDC  is  a  3  star  officer  that  is  the  executive  agent  to  the  Commandant  of  the  Marine  Corps  for 
Combat  Development. 

Author’s  Note:  Recent  changes  to  the  process  have  been  annoimced.  The  Assistant  Commandant  of 
the  Marine  Corps  (ACMC)  wiU  now  approve  all  Requirements  Documents  for  the  Marine  Corps.  It  is 
not  clear  whether  the  ACMC  has  assumed  chairmanship  of  the  CAC  or  if  another  forum  for  review 
has  been  organized  at  the  Pentagon. 

A  Capabilities  Assessment  Council  (CAC)  controls  the  Marine  Corps  front-end  process.  The  CAC  is 
the  senior  decision  making  body  for  DOTES  (Doctrine,  Organization,  Training  and  education. 
Equipment,  and  Support  and  facilities)  assessments.  These  assessments  are  done  to  help  make  the 
hard  decisions  between  current  deficiencies  and  future  requirements.  The  CAC  meets  on  a  quarterly 
basis  and  includes  membership  from  all  process  owners  as  well  as  Marine  Expeditionary  Forces  and 
other  marine  forces.  The  members  are  Colonels  and  the  Deputy  Commanding  General,  MCCE)C  (2- 
star  officer),  chairs  the  committee.  Additionally,  there  is  a  CAC  Working  Group  (GAWG)  that  reviews 
aU  Future  Marine  Force  (FMF)  Operational  Need  Statements  (FONS).  Potential  FONS  and  other 
deficiencies  are  initially  submitted  to  the  Requirements  Division  of  the  Warfighting  Development 
Integration  Division  (WDID)  and  MGGDC  for  review  and  action  by  the  operating  forces.  In  addition 
to  the  FONS,  there  are  other  sources  of  information  seeking  entrance  to  the  Marine  Corps  front-end 
process.  Some  of  the  sources  are  National  Military  Strategy,  CINC’s  Integrated  Priority  Lists, 
Experimental  results.  Marine  Corps  Master  Plan,  Wargames,  Mission  Area  Analyses  (MAAs), 
Advanced  concept  Technology  Demonstrations  (ACTDs),  Defense  Science  Board,  Marine  Corps 
Lessons  Learned  System,  etc. 

The  overall  process  is  presented  below. 
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Figure  51.  Diagram  of  Process  Flow  for  Marine  Corps  front-end  process 

One  organization  within  the  MCCDC,  WDID,  is  responsible  for  most  of  the  front-end  activities. 
WDED  takes  a  holistic  view  of  needs  and  requirements  by  using  the  DOTES  framework.  The 
‘Equipment’  portion  of  the  framework  primarily  addresses  Requirements  and  Material  needs,  but  any 
new  need  or  requirement  imparts  all  of  the  other  elements  of  the  framework.  By  acknowledging  this, 
the  Marine  Corps  hopes  to  produce  integrated  capabilities  for  the  Marine  Corps. 

The  Marine  Corps  has  eight  core  processes.  These  are  Concept  Based  Requirements,  Resource 
Allocation,  Total  Force  Structure,  Human  Resource  Development,  Material  Lifecycle  Management, 
Infrastructure  Management,  Information  Management,  and  Service  Advocacy.  WDID  is  responsible 
for  integration  across  both  Functional  Areas  and  Processes.  The  following  diagram  illustrates  the 
Concept-Based  Requirements  Process  through  which  all  the  processes  are  imparted. 
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Figure  52.  Diagram  of  the  Concept-Based  Requirements  Process  Flow 

The  WDID  Requirements  Division,  as  mentioned  earlier,  is  the  focal  point  where  all  initial 
requirements  documents  (like  a  FONS)  are  collected  for  evaluation  by  the  Concept  Development 
System.  Upon  receipt  of  a  potential  FONS,  or  upon  the  decision  of  the  CAC  that  a  deficiency 
identified  by  other  means  requires  a  material  solution,  the  Requirements  Division  assigns  an  Aaion 
Officer  to  write  and  develop  the  FONS.  This  Action  Officer  staffs  the  FONS  to  various  MCCE)C 
and  Headquarters  Marine  Corps  (HQMC)  agencies  for  review  and  comments.  (Unfortunately,  the 
review  and  comment  process  can  introduce  excessive  or  indefinite  delays  into  the  overall  process. 
This  can  occur  at  any  of  the  several  review  stages  that  exist  within  the  process  as  well.)  Once  all 
comments  have  been  resolved,  the  FONS  is  screened  by  the  CAWG.  Pending  no  issues  that  require 
further  resolution,  the  FONS  is  reviewed  by  the  CAC.  An  approved  FONS  is  prioritized  into  the 
MCCDC  Priority  List  that  is  submitted  to  the  POM  Working  Group  (PWG)  for  consideration.  The 
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process  by  which  the  FONS  is  prioritized  is  nearly  identical  to  the  method  used  by  the  Army.  The 
Marine  Corps  has  a  division  that  also  reports  directly  to  the  Commanding  General  MCCDC  called  the 
Warfighting  Lens  Division.  This  division  conducts  the  Warfighting  Lens  Analysis  on  all  needs  and 
requirements. 

Should  the  FONS  be  programmed  into  the  budget,  the  preparations  for  ORD  development  begin. 
There  are  9  steps  in  this  process.  The  first  action  is  the  issuance  of  an  Acquisition  Decision 
Memorandum.  This  document  indicates  that  money  is  available  to  begin  work  on  the  FONS  and  also 
names  the  Program  Manager  for  the  Acquisition  Portion  of  the  effort. 

The  second  action  that  occurs  is  the  development  of  the  ORD  Integrated  Product  Team  (IPT).  The 
IPT  members  are  permanent.  They  remain  part  of  the  team  throughout  the  life  of  the  program  and 
the  various  ORD  iterations  that  occur  during  the  different  acquisition  phases.  There  are  three  core 
members  on  the  IPT.  The  first  member  is  from  MCCDC  and  is  called  the  ‘Requirements  Officer 
(RO)’.  The  second  core  team  member  is  from  the  Marine  Corps  Acquisition  Corps  and  is  called  the 
‘Project  Officer  (PO)’.  This  person  is  not  the  Program  Manager,  but  acts  as  a  liaison  between  the 
program  manager  and  the  ORD  IPT.  The  third  core  team  member  is  from  the  Marine  Corps 
Operational  Test  and  Evaluation  Division  and  is  called  the  ‘Operational  Test  Project  Officer  (OTPO)’. 
Other  team  members  from  other  organizations  are  added  as  required.  The  Requirements  Officer 
chairs  the  IPT. 

The  third  step  is  for  the  Requirements  Officer  to  produce  an  initial  draft  of  the  ORD  that  is  as  specific 
as  possible.  He  identifies  preliminary  issues  and  Key  Performance  Parameters  (KPPs)  as  much  as 
possible.  Many  items  are  likely  to  be  left  unspecified  at  this  early  stage  in  the  ORD  development. 

The  fourth  step  is  where  the  IPT  reviews  the  ORD  and  makes  a  recommendation  for  an  Analysis  of 
Alternatives  or  a  Request  for  Alternative  Approval  (ATDs,  ACTDs,  etc.).  There  are  specific  criteria 
that  identify  which  route  of  analysis  is  most  appropriate. 

The  fifth  step  is  to  conduct  the  AoA.  These  are  of  varying  complexity  and  length.  The  alternative 
approval  route  puts  the  initiative  into  different  processes.  Upon  completion,  (of  an  ACID  for 
instance),  an  ORD  has  to  be  written  based  upon  the  outcome  of  the  alternative  processes. 
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The  sixth  step  is  to  integrate  the  analysis  of  the  AoA  and  other  analyses  into  the  ORD.  The  ORD  is 
refined  so  that  defendable  rationale  exists  throughout  the  document.  Additionally,  two  additional 
appendices  to  the  ORD  are  created.  The  first  one  is  a  dendritic  map  that  shows  the  relationship  of  all 
of  the  requirements  to  the  different  communities  (the  user,  the  acquirer,  and  the  tester).  The  second 
appendix  gives  the  requirements  history  and  rationale. 

At  this  point  (the  seventh  step),  the  ORD  is  ready  for  staffing  throughout  the  Marine  Corps  and  other 
services.  Internally,  the  ORD  goes  through  the  CAWG,  and  then  the  CAC  to  ensure  that  they  support 
the  current  doctrine,  adhere  to  the  approved  standards,  and  architectures,  and  comply  with  the  existing 
planning  guidance.  Usually  this  process  both  internally  and  externally  is  about  45  days  long. 

After  the  staffing,  the  IPT  must  resolve  all  comments  that  have  been  received  (during  this  eighth  step). 
Upon  resolution  of  those  comments  (and  the  unspecified  time  to  resolve  the  comments),  the  IPT 
submits  the  ORD  for  approval  to  the  Commanding  General,  MCCDC.  With  the  CGs  validation,  it  is 
forwarded  to  the  Assistant  Commandant  of  the  Marine  Corps  (ACMC),  who  approves  the  ORD  (the 
ninth  step).  If  there  is  Joint  interest  in  this  ORD,  it  must  be  approved  by  the  Joint  Requirements 
Oversight  Committee  (JROC).  The  process  for  the  JROC  has  been  elaborated  upon  in  other  case 
studies.  The  major  change  to  the  process  is  that  a  few  more  review  layers  are  added  to  the  process, 
and  also  the  ACMC  validates  the  ORD  as  the  Marine  Corps  position  and  the  JROC  will  approve  it. 

Or^amzational  Issues 

The  Marine  Corps  uses  the  CAC  as  the  gatekeeper  to  the  front-end  of  the  Marine  Corps  process. 
Overall  the  front-end  process  consists  of  several  screens  prior  to  a  Milestone  I  decision.  There  are  at 
least  six  screening  funaions  prior  to  the  approval  stage  or  prior  to  entering  the  ‘joint’  environment. 
Not  all  of  these  screens  are  explicit.  The  POM  development  process  also  acts  as  an  implicit  screen  as 
well. 

With  the  exception  of  resources,  the  entire  front-end  process  is  located  within  one  organization.  The 
notion  of  integration  across  all  of  the  different  processes  and  functions  is  instilled  within  the 
organization.  This  is  expressed  not  only  in  the  organizational  design  of  their  process,  but  with  the 
assignment  of  one  Action  Officer  to  develop  the  TONS  and  a  core  IPT  to  develop  the  ORD. 
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Business  Issues 

Resource  Allocation  is  kept  separate  from  the  Combat  Development  Organization.  The  CEXH  simply 
has  input  into  the  POM  building  process  through  the  WFLA.  The  PPBS  of  the  Marine  Corps  has  to 
make  the  prioritization  decisions  on  which  new  development  programs  to  fund  and  how  to  interpret 
the  information  advocated  by  the  WFLA  output. 

Overall  strategy  of  the  Marine  Corps  has  been  distilled  throughout  the  organization  through  their 
DOTES  framework  and  impacts  all  areas  of  their  decision  making  process.  It  is  not  clear  that  the 
POM  process  reflects  the  holistic  view  the  DOTES  process  forces  on  the  front-end  development 
activities. 

Summary 

Overall,  the  Marine  Corps  front-end  process  contains  most  of  the  elements  of  the  idealized  front-end 
process,  however  it  is  not  idealistic.  Their  process  can  be  characterized  as  one  with  multiple  screens 
and  one  with  disconnerts  between  the  weapon  system  development  process  and  the  resourcing 
process.  This  separation  is  a  distinct  disadvantage. 


202 


Front-End  Process  Flow 


Identification 


Initial 

Screening 


Concept 

Development 


Business  Case 
Development 
/  Final  Screen 


Separate  process  outside  the 
control  of  the  CAC 


Separate  process  outside  the 
control  of  the  CAC 


Figure  53.  Marine  Corps  Front-end  in  Terms  of  the  Framework 

The  Corps’  front-end  process  recognizes  the  importance  of  holistic  thinking  and  the  approach  toward 
integrative  capabilities  for  the  entire  Marine  Corps.  Using  Aaion  Officers  and  the  Core  IPT 
approaches  for  developing  the  need  statements  and  requirements  documents  is  a  positive  step. 
However,  the  process  is  open  to  multiple  review  stages  where  comment  resolution  can  delay  the 
process  excessively  or  indefinitely. 

Additionally,  the  Marine  Corps  process  targets  in  advance  the  kind  of  solution  that  is  preferred.  This 
happens  by  writing  a  draft  ORD  prior  to  conduaing  the  AoA.  By  so  doing,  the  AoA  can  be 
effectively  tailored  so  as  to  favor  the  preferred  outcome  from  the  very  beginning. 
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Unified  Commands 

These  additional  case  studies  represent  special  cases  in  Requirements  Development.  One  organization 
is  allowed  to  pursue  product  development  programs  under  its  own  authority.  It  represents  a 
microcosm  of  the  other  larger  produrt  development  processes  of  the  other  services.  The  remaining 
three  cases  represent  only  a  portion  of  the  front-end  of  product  development.  These  three  cases  share 
an  analog  with  those  companies  that  are  primarily  end  users  of  another  company’s  products,  although 
their  organizations  are  vastly  different  from  each  other  as  well  as  the  missions  they  perform. 

US  Special  Operations  Command 

This  organization  is  a  joint  command  consisting  of  different  service  counterparts.  It  is  unique  in  that 
this  command  has  its  own  PPBS  process  and  budgeting  authority  entirely  separate  from  the  other 
elements  of  the  US  Military  and  have  a  Total  Obligation  Authority  of  about  $3.3  BOlion.  About  25% 
($600M  per  year)  of  that  is  for  modernization  -  and  is  shrinking  every  year.  The  modernization 
account  is  the  one  used  to  also  pay  for  contingencies  that  have  not  been  budgeted  for. 

The  process  used  by  this  organization  is  called  the  Strategic  Planning  Process  (SPP).  It  includes  the 
PPBS,  Requirements  Generation,  and  interfaces  with  Acquisition.  This  organization  developed  after  a 
critical  process  review  found  that  the  overall  ^stem  contained  problems  with  guidance,  integration, 
process  discipline,  and  analysis. 

The  Materiel  Requirements  Process  is  the  US  SOCOM  process  to  deal  with  requirements  generation 
and  validation.  Foremost,  the  warfIghter/commands  identify  the  deficiencies.  As  inputs,  the 
commands  use  information  derived  from  the  Strategic  Planning  Process  guidance.  Mission  Area 
Analyses,  Capabilities  Assessments,  and  Operational  Activities.  One  organization  at  this  unified 
command  validates  requirements.  US  SOCOM  does  conduct  some  Future  Concept  Working  Groups 
(FCWG)  and  also  does  some  Long-range  Planning  that  the  components  (the  different  service 
counterparts  that  comprise  USSOCCOIv^  can  use  as  inputs  to  their  front-end  processes  (an  example 
of  this  is  the  Integrated  Priority  List  (IPL)  USSOCOM  creates  every  year). 

The  individual  service  components  condua  their  own  front-end  processes.  This  includes  the 
identification  of  deficiencies.  The  actual  writing  of  Requirements  documents  is  done  within  the 
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component  command’s  organization.  It  is  also  staffed  within  the  command  for  comments  and 
resolution  before  it  gets  to  US  SCXilOM.  The  following  diagram  illustrates  the  process. 


Figure  54.  US  SOCOM  Requirements  Generation  Process  Flow  Chart 

When  a  document  is  received  at  US  SOCOM,  the  organization  responsible  for  Requirements 
Documents  is  the  Operations  and  Plans  (OP)  division.  OP  will  assign  one  of  about  13  Program 
Requirements  Officers  (PROs)  to  the  document.  That  individual  is  responsible  to  see  that  the 
document  is  staffed  for  ‘clarity  of  deficiency’,  level  of  required  analysis’,  and  ‘fidelity  of  solution.’  One 
of  the  first  screens  used  is  that  of  ‘joint  potential’  (i.e.  the  potential  of  this  requirement  to  be  valid  for 
more  than  one  service).  If  a  document  indicates  this  is  the  case,  it  must  be  staffed  to  the  other 
component  commands  as  well  as  the  other  services  outside  of  SOCOM.  Once  all  comments  are 
gathered  and  resolved,  the  PRO  takes  the  document  to  either  one  of  two  approval  boards  -  depending 
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upon  the  contentious  nature  of  the  effort.  A  document  that  does  not  have  a  lot  of  ‘attention’  or 
baggage  attached  to  it  will  go  before  a  board  (of  5  one-star  officers).  They  meet  only  as  required  -  if 
there  are  enough  documents  queued  up  as  to  make  a  meeting  worthwhile.  More  politically  charged 
documents  go  before  a  higher  level  board  (three-star  officers)  at  which  the  decision  is  made. 

This  organization  has  about  40  to  60  documents  a  year  traverse  the  system  (vs.  the  entire  Air  Force’s 
100  or  so  documents).  Some  can  get  through  the  validation  phase  within  30  days.  Those  that  are 
politically  charged  can  take  much  longer  -  sometimes  years.  However,  having  a  Validated  document 
doesn’t  mean  there  is  any  money  involved.  It  just  means  that  US  SCXIIOM  has  defined  a  deficiency 
and/ or  an  Operational  Need.  Mission  Need  Statements  (MNS)  require  approximately  30  to  60  days  to 
get  through  the  process  (99%  get  through  in  30  days).  Operational  Requirement  Documents  (ORD) 
require  anywhere  from  30  to  60  days. 

Validated  documents  are  approved  once  a  year  by  an  annual  evaluation  of  the  SOCOM  General 
Officer/Fleet  Officer  commanding  the  SOCOM.  This  is  the  closest  point  US  SOCOM  gets  to  a  tme 
Business  Case  Decision  Forum.  Decisions  are  made  with  some  sense  of  the  cost  and  urgency  attached 
to  each  document,  however,  resources  decisions  are  not  made  in  this  forum.  Following  approval,  all 
requirements  compete  within  the  Strategic  Planning  Process  (SPP)  for  funding.  The  Prioritization  and 
funding  of  requirements  is  determined  during  the  Capability  and  Program  Assessment  Phases  of  the 
SPP.  There  are  five  different  assessment  areas  that  the  document  could  be  evaluated  in  (e.g.  strike, 
engage,  support,  C4I,  mobility).  The  most  appropriate  one  is  chosen.  Then,  all  requirements  in  these 
assessment  areas  are  evaluated  and  prioritized  based  upon  extensive  modeling  and  simulation. 
Integrated  Concept  Teams  (ICT)  evaluate  the  modeling  and  simulation  results.  These  teams  use 
mathematical^’  driven  scoring  (QFD)  to  build  the  rack  and  stack  list.  Of  course,  these  lists  are  always 
subject  to  ‘override  authority’  by  their  bosses. 

The  Program  Objective  Memorandum  (POM)  is  built  based  upon  the  rack  and  stack  lists  that  are 
created.  The  five  different  assessment  area  directors  must  work  together  to  build  the  overall  SOCOM 
prioritized  list  and  with  the  POM  builders  in  the  SPP. 

Generally  speaking,  only  about  10%  (4  to  6)  of  documents  in  any  given  year  are  funded.  However, 
this  is  not  seen  as  a  poor  thing  by  the  warfighter.  Rather,  the  CINCs  would  rather  have  an  approved 
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document  that  can  be  ‘activated’  at  any  time  in  case  money  breaks  free  (end  of  year  fallout  money, 
etc.).  Currently,  there  are  about  200  to  250  approved  Requirements  documents  that  are  awaiting 
action.  These  approved  (but  deferred)  documents  are  reviewed  on  an  annual  basis  or  whenever  the 
PRO  is  changed  to  verify  the  requirement  is  stiU  valid. 

When  a  requirements  document  is  funded,  the  funding  includes  the  entire  projected  funding  stream 
from  Phase  0  activities  to  retirement  of  a  system.  The  funds  are  dispersed  to  the  service  components 
according  to  the  type  of  system  development  that  will  be  going  on.  Therefore,  the  funding  for  a 
system  includes  resources  for  an  Analysis  of  Alternatives  (AoA)  from  the  very  beginning.  Mostly 
contractors  with  SOMCOM  oversight  conduct  these  AoAs.  The  service  component  has  a  much  more 
active  role  with  the  AoA  contractor  mostly  because  the  service  component  is  responsible  for 
dispersing  the  money.  The  component  command  uses  the  results  of  the  AoA  to  prepare  the  ORD  for 
SOCOM  validation  and  approval.  The  AoA  is  considered  to  be  one  of  the  key  studies  in  preparing 
the  initial  ORD. 

In  order  to  spend  money  allocated  to  a  system  development  projea,  the  USSOCOM  Acquisition 
Executive  must  release  an  Acquisition  Decision  Memorandum  (ADM).  This  is  the  same  kind  of 
ADM  that  each  of  the  services  use.  The  ADM  references  the  applicable  requirement  document  as 
being  validated  and  approved  by  the  proper  authority  and  also  certifies  that  money  has  been  allocated 
and  is  available  for  the  system  development.  The  same  process  is  used  at  each  milestone,  whether  for 
a  Mission  Need  Statement  or  for  an  Operational  Requirements  Document. 

Additionally,  as  USSOCOM  is  a  unified  command,  it  is  required  to  submit  an  Integrated  Priority  Dst 
(IPL)  to  the  JROC.  Also,  USSOCOM  may  use  the  Joint  Warfighter  Capabilities  Assessment  (JWCA) 
process  to  tiy  to  obtain  the  resources  necessary  purchase  or  fund  any  requirement  that  outstrips 
USSOCOM’s  resources. 

Orgmizatioml  Issues 

The  SOCOM  process  is  conducted  by  a  small  group  of  people  working  together.  The  small  numbers 
of  people  the  PROs  need  to  know  at  the  service  component  level  facilitates  some  of  the  organizational 
functioning.  The  process  flows  much  more  smoothly,  according  to  USSOCOM,  because  of  the  small 
organizational  size. 
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There  are  two  distinct  processes  that  are  required  to  agree  in  order  for  a  requirement  to  be  able  to 
receive  funding  for  further  development,  the  Materiel  Requirements  Process  and  the  Strategic 
Planning  Process.  These  processes  operate  independently  of  one  another. 

Business  Issues 

According  to  USSOCOM,  Mission  Area  Plans  developed  by  the  service  components  seem  to  be 
disconnected  from  the  overall  priorities  of  USSOCOM  The  Mission  Area  Plans  (MAPs)  of  the 
different  service  components  do  not  directly  correlate  to  the  five  capability  assessment  areas  SOCOM 
uses.  MAPs  tend  to  be  built  along  service  ‘core  competencies’  and  don’t  translate  easily  to  the 
SOCOM  categories. 

They  currently  do  not  have  a  single  IT  solution  to  track  requirements.  They  are  awaiting  the  approval 
of  IRSS  and  are  currently  using  a  variation  of  Excel  databases,  Access  databases,  and  paper  tracking 
mechanisms. 

USSOCOM  is  also  willing  to  accept  money/ resources  from  any  service  that  wishes  to  participate  in  a 
development  project.  This  brings  additional  resources  to  the  project  that  it  otherwise  wouldn’t  receive. 
This  allows  SOCOM  to  leverage  the  resources  that  are  added  to  the  SOCOM  resources  to  pursue 
other  SOCOM  priorities.  However,  these  additional  resources  are  funneled  directly  to  the  individual 
service  component  rather  than  to  USSOCOM  for  distribution. 

Summary 

This  organization  is  a  microcosm  of  the  US  defense  department.  Each  service  component  conducts 
the  front-end  portion  of  the  process,  to  include  the  derivation  of  needs  and  the  building  of  the  initial 
requirements  document  (MNS).  From  this  organization’s  perspective,  the  individual  services  vary  in 
their  abiKty  to  identify  deficiencies.  This  variability  manifests  itself  during  a  requirement  document 
review.  Some  documents  are  better  written  than  others  are  and  this  variation  seems  to  vary  largely  by 
service. 
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USJFCOM  used  to  be  known  as  ACOM,  or  the  Atlantic  Command.  This  changed  in  1998  when  it 
was  renamed  the  US  Joint  Forces  Command.  This  is  a  joint  service  command  (one  of  nine)  with 
Headquarters  in  Norfolk  VA.  There  are  five  joint  commands  with  Geographic  Areas  of  Responsibility 
(such  as  the  Atlantic  area)  and  four  with  Funaional  Areas  of  Responsibility  (such  as  Special 
Operations  and  Space  Assets.)  In  early  1999,  the  USJFCOM  commander  was  deputized  by  the  other 
joint  warfighting  commanders  to  art  as  THE  advocate  for  Requirements  Issues  to  the  DoD  (CJCS 
1999).  USJFCOM  is  to  be  the  “Chief  Advocate  of  Jointness”.  It  has  assumed  the  role  of  America’s 
joint  force  integrator,  trainer  and  provider;  and  architect  for  the  future  of  America’s  military. 
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Recent  modifications  to  the  Title  X  statutes,  particularly  through  the  Goldwater-Nichols  reforms, 
named  the  Chairman  of  the  Joint  Chiefs  of  Staff  responsible  to  prioritize  a  list  of  needs  and 
requirements.  This  legislation  has  since  been  interpreted  to  mean  that  the  Joint  Commanders  should 
put  together  a  priority  list  and  send  these  to  the  appropriate  service  component  commanders  (such  as 
ACC  or  N8  or  MCCDC)  so  that  they  pursue  the  appropriate  system  development.  This  list  is  known 
as  the  Integrated  Priority  List  or  IPL. 

The  process  to  build  the  IPL  is  shown  graphically  in  the  diagram  below.  The  process  follows  in  this 
fashion:  some  time  in  July,  the  DoD  sends  out  guidance  to  the  joint  command  Commander  -  in  - 
Chiefs  (CnXCs)  on  how  to  build  the  IPL.  USJFCOM  sends  the  same  message  out  to  its  different 
service  component  commanders  (within  USJFCOM)  almost  immediately  afterward.  The  final  IPL  is 
published  in  December. 
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Figure  56.  USJFCOM's  Front-end  Process 

USJFCOM  J-8,  Requirements  Interoperability  and  Strategy^  Directorate  owns  the  process.  A  two-star 
officer,  who  reports  direaly  to  the  USJFCOM  Chief  of  Staff  (COS),  heads  J-8.  The  COS  reports  to 
the  Deputy  CINC  (DCINC),  a  three-star  officer,  who  reports  to  the  CINC,  a  four-star  officer.  The  J- 
8  uses  general  survey  techniques  to  gather  user  needs  (i.e.  the  request  sent  to  each  component).  When 
the  user  needs  are  collected,  a  process  of  combining  redundant  needs  goes  on.  Simultaneously,  very 
limited  studies  and  analyses  are  done  on  some  of  the  items  that  appear  to  be  important  (based  upon 
the  criteria  of  the  CBSfC).  These  studies  and  analyses  are  not  very  thorough  or  numerous  -  the  CINC 
has  neither  the  time  nor  resources  for  many  of  these.  USJFCOM  has  the  smallest  headquarters 
organizational  staff  of  any  of  the  other  unified  commands.  Despite  the  organizational  size,  USJFCOM 
feels  that  extensive  use  of  Knowledge  Management  techniques  will  offset  any  negative  impacts  of  a 
smaller  staff. 


211 


The  last  step  to  build  the  IPL  is  the  prioritization  process.  This  step  requires  the  most  time  and  is 
highly  political  in  nature.  It  is  wholly  dependent  upon  the  decision  of  the  CINC.  In  general  the  IPL  is 
not  resource  constrained.  This  is  attributable  to  the  fact  that  the  warfighter  is  not  as  aware  of  the 
potential  costs  of  a  need  or  ‘solution’.  Additionally,  it  is  likely  that  the  ‘needs’  look  more  like 
‘solutions’  to  specific  problems  that  exist. 

Within  USJFCOM  there  is  a  lot  of  discussion  about  how  to  even  put  the  IPL  together;  usually  it 
revolves  around  the  criteria  used  during  the  building  of  the  list.  In  order  to  understand  the  criteria 
used,  a  brief  discussion  is  required.  First,  most  Joint  commanders  are  near  or  at  the  end  of  their 
careers.  They  are  only  involved  with  the  joint  command  for  1  to  3  years.  Therefore,  their  focus  is 
on  immediate  and  short-term  requirements  (1  to  2  years  out).  The  other  issue  is  one  where  the  IPL  is 
used  in  the  PPBS  system.  Most  of  the  service  POMs  are  already  in  their  final  stages  by  December, 
therefore,  most  of  the  IPL  feedback  is  noted  but  not  really  acted  upon.  Second,  the  inherent  time 
required  by  the  process  is  such  that  by  the  time  the  requested  item  is  even  funded,  the  CINC  may  have 
already  retired  and  another  commander  is  there  (with  different  priorities). 

Additionally,  the  unconstrained  nature  of  the  IPL  is  reinforced  by  the  actions  of  the  PPBS.  If  every 
single  item  currently  used  or  valued  for  use  by  the  warfighter  is  not  listed,  even  those  items  whose 
funding  is  seemingly  secure  or  already  exists  runs  the  risk  of  not  getting  additional  funding  or  even 
losing  resources  (“because  it  wasn’t  in  their  IPL”).  These  programs  become  targets  for  budget  cutters 
during  the  never-ending  PPBS  cycles. 

The  last  recourse  for  CINC  priorities  to  get  the  necessary  funds  come  through  the  JWCA  process  (the 
Joint  Warfighter  Capability  Assessment).  Here  the  CINCs  can  petition  the  Joint  Chiefs  of  Staff  0CS) 
for  funding  or  redirection  of  programs  within  the  budget.  Details  are  unavailable  on  the  frequency  the 
JWCA  process  being  used  in  this  fashion.  If  there  is  a  need  that  absolutely  must  be  met,  the  IPL 
requirement  is  usually  met  through  emergency  budget  supplemental  actions. 

Or^aniiational  Issues 

CINCs  wishes,  agenda,  and  desires  drive  the  prioritization  process  of  the  joint  commands.  These 
invariably  change  from  year  to  year  and  commander  to  commander.  Reacting  to  these  changes  likely 
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introduces  turbulence  into  the  system.  Furthermore,  the  responsiveness  of  the  system,  or  lack  thereof, 
is  fueled  by  the  long  cycle  times. 

One  of  the  strengths  of  the  joint  command’s  perspective  is  that  it  is  integrated.  Each  branch  of  the 
service  plays  an  integrated  part  in  the  execution  of  the  commands  activities.  Therefore, 
interoperability  among  the  services,  for  instance,  receives  the  greatest  priority.  They  are  focused  on 
the  mission  and  are  more  concerned  by  the  accomplishment  of  the  mission  than  by  inter-service 
rivalries  (although  they  stiU  exist). 

Business  Issues 

USjFCOM  has  no  resources  of  its  own  for  product  development.  It  relies  upon  the  respective  military 
branch’s  component  commander  to  pursue  product  development.  It  does  have  a  limited  support 
budget  for  the  activities  of  its  headquarters  staff.  For  instance,  an  air  related  issue  would  be  funded  by 
the  Air  Force  and  handled  by  the  Air  Force’s  Air  Combat  Command  once  notified  of  the  need  by 
USJFCOM.  (Should  this  occur,  this  aaion  would  be  an  example  of  ‘top-down  direction’  and  the 
requirement  would  not  likely  be  found  in  the  service’s  MAP.)  The  military  is  organized  such  that 
component  commanders  are  empowered  to  ‘train  and  equip’  while  the  joint  commanders  are  to  ‘fight 
and  win’.  This  is  a  legislated  division  (currently  found  in  Title  X  statutes  of  the  US  Government). 

USJFCOM  would  like  to  expand  its  role  in  Requirements  Advocacy.  In  its  role,  the  J-8  would  like  to 
receive  and  integrate  all  of  the  unified  IPLs  into  one  standalone  document.  Additionally,  J-8  would 
Hke  all  requirements  documents  (regardless  of  their  size  and  scope)  to  be  reviewed  and  pass  through 
their  organization.  However,  this  is  not  yet  practical  at  this  time  considering  the  size  of  the  staff  in  J-8 
-  but  it  is  in  their  long-rang  plan.  The  command  also  has  indicated  a  desire  to  have  a  seat  on  the 
JRC)C,  but  the  rationale  for  this  desire  is  unknown. 

Summary 

Overall,  USJFCOM  has  a  defined  front-end  process,  albeit  an  abbreviated  one.  Its  role  as  the  ‘Chief 
Advocate  for  Requirements’  is  relatively  new  (about  1  year  old).  It  uses  a  method  (a  survey  -  although 
it  is  one  that  will  not  be  treated  the  same  way  in  each  service)  to  elicit  user  needs.  Their  method  tries 
to  screen  ideas  by  collating  them  and  organizing  them  in  a  fashion.  Additionally,  some  analysis, 
although  it  is  quite  scarce  in  depth  and  rigor,  is  done. 
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Figure  57.  USJFCOM's  Front-end  in  Terms  of  the  Framework 


The  above  diagram  seems  to  indicate  that  this  process  somehow  leads  to  a  business  case.  This  is  not 
so.  However,  it  does  contain  elements  of  the  idealized  framework,  such  as  initial  screening,  analysis,  as 
well  as  final  approval  that  warrant  the  presentation  of  the  process  flow  as  shown  above.  However,  in 
reahty  this  process  is  the  very  front-end  for  many  other  processes  in  different  branches  of  the  military 
(if  viewed  as  an  input  to  the  different  service  planning  processes). 

One  clear  weakness  is  in  the  area  of  analysis.  The  weakness  is  that  the  organization  does  not  have 
enough  resources  to  adequately  do  its  job  to  analyze  the  alternatives  that  exist  between  the  services  for 
a  mission  task. 

Nevertheless,  a  strength  of  the  process  is  the  IPL  is  an  integrated  look  -  not  for  just  one  service,  but 
for  the  warfighter  how  to  best  accomplish  the  mission  task.  One  area  of  concern  might  be  the  lack  of 
the  process  being  able  to  distinguish  between  true  needs  of  tomorrow  and  outright  solutions  for  today. 
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Many  would  argue  that  due  to  the  short-term  nature  of  these  lists,  this  is  a  strength.  Indeed,  many  of 
these  needs  can’t  go  through  the  drawn  out  product  development  process  of  the  military.  The  IPL 
may  serve  as  finding  the  right  balance  between  the  immediate  pressing  tasks  of  today  and  preparing  for 
the  future  long-term  capabdrty. 

NORAD  Front-end  process 

NORAD  is  the  North  American  Aerospace  Defense  Command.  It  is  a  bi-national,  joint-service 
command  between  the  United  States  of  America  and  Canada.  This  is  a  unique  relationship,  as  their 
processes  must  correspond  with  those  of  two  countries.  It  has  control  over  its  resources  in  a  similar 
fashion  to  the  US  Air  Force’s  MAJCOMs.  Actual  product  development  is  spread  between  the  two 
countries  and  their  respective  acquisition  processes.  It  is  also  unique  in  that  it  may  generate  Mission 
Need  Statements  as  a  service  does. 

NORAD  began  with  an  agreement  with  Canada  in  1958.  This  agreement  has  been  renewed  eight 
times  and  the  latest  renewal  was  in  1996.  It  currently  has  two  missions:  Aerospace  Warning  and 
Aerospace  Control.  NORAD  begins  its  front-end  process  by  conducting  a  Mission  Area  Analysis 
(MAA).  The  inputs  for  this  are  varied  and  include  threats,  policy,  technology,  budget,  capability, 
strategy,  and  doarine.  As  part  of  the  MAA,  NORAD  wiU  determine  capability  shortfalls,  deficiencies 
or  opportunities  and  state  these  in  terms  of  a  Mission  Need. 

The  following  diagram  illustrates  the  high  level  process  that  exists  for  product  development  for 
NORAD.  More  detailed  discussion  about  the  elements  of  the  process  are  found  after  the  diagram. 
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Figure  58.  NORAD  Implementation  of  Requirements 


There  are  three  basic  activities  of  NORAD  in  terms  of  requirements.  The  first  is  preparing  a  Mission 
Area  Analysis  (MAA).  The  second  is  preparing  an  Integrated  Priority  List  (IPL).  The  third  is  the 
preparation  of  any  Mission  Need  Statements  (MNS). 
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Figure  59.  Flow  of  Mission  Area  Analysis  of  NORAD 

A  cross-functional  team  that  reviews  all  of  the  different  inputs  and  conducts  analysis  on  those  inputs 
conducts  Mission  Area  Analysis.  There  are  five  teams  that  conduct  a  Mission  Area  Analysis.  The 
process  lasts  approximately  one  month  and  their  output  is  a  report  for  each  team  that  contains  their 
findings.  These  individual  reports  are  reviewed  and  consolidated  by  a  Vision  Implementation 
Committee.  There  are  9  members  on  the  committee,  plus  a  secretary  and  chairman.  The  Director  of 
Plans,  a  one-star  officer,  chairs  the  committee.  Other  members  represent  planning,  requirements. 
Manpower  &  Persoimel,  Intelligence,  Operations,  Logistics,  Command  &  Control,  and  Analysis. 
These  members  are  all  Colonels  or  their  equivalent.  The  committee  produces  a  draft  report.  Once  the 
draft  report  is  put  together,  it  is  sent  for  review  to  the  different  internal  staffs  within  NORAD  as  well 
as  the  Force  Providers  (US  Space  Command  and  the  Canadian  Space  Equivalent).  Feedback  is 
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obtained  and  reviewed  by  the  Vision  Implementation  Qjmmittee.  This  process  requires 
approximately  3  months  to  complete. 

Once  all  of  the  different  comments  are  consolidated  and  resolved,  the  updated  draft  report  is  sent  to 
the  General  Officer  Steering  Group  (GOSG)  for  approval.  Approval  actions  require  approximately 
one  month  to  complete.  Once  this  is  approved,  the  report  is  finalized,  published,  and  distributed.  The 
report  is  NORAD's  baseline  document  for  identifying  deficiencies.  It  is  called  the  NORAD  Mission 
Area  Analysis  Report  (NMAAR).  This  document  is  the  foundation  for  the  Integrated  Priority  List 
(IPL)  development.  It  is  also  the  source  for  new  Mission  Need  Statements,  as  well  as  Non-MNS 
correaive  aaions. 


Figure  60.  NORAD  process  for  Integrated  Priority  List  (IPL) 

Development 
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The  Vision  Implementation  Committee  does  the  IPL  development.  The  committee  collates  the 
different  issues  present  in  the  NMAAR  and  prepares  a  ballot  of  those  issues.  This  ballot  is  sent  to  the 
staffs  and  also  the  force  providers  to  be  returned  to  the  committee  with  a  subjective  ranking  on  which 
issues  are  more  important  than  other  ones  are.  This  process  requires  approximately  two  months. 

The  Committee  takes  these  inputs  and  drafts  a  new  document  called  the  Integrated  Priority  List  Draft. 
The  draft  is  again  sent  to  the  staffs  and  also  to  the  Force  providers  for  comments  and  review.  The 
comments  and  remarks  are  addressed  and/ or  resolved  before  moving  to  the  next  step  of  the  process. 
This  step  requires  approximately  two  months. 

For  the  final  approval  of  the  IPL,  the  vision  implementation  committee  sends  the  updated  draft  IPL  to 
the  General  Officer  Steering  Group.  This  Group  deliberates  over  the  particulars  of  the  document  and 
gives  their  approval  in  one  to  three  months  time,  depending  on  the  content  of  the  IPL.  When 
approved,  the  IPL  goes  to  US  Space  Command  (as  well  as  the  component  commanders  and  their 
counterparts  on  the  Canadian  side)  for  their  use. 
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Figure  61.  NORAD  Mission  Need  Statement  Process 

When  NORAD  determines  to  write  a  Mission  Need  Statement,  the  Vision  Implementation 
Committee  designates  a  particular  office  to  be  responsible  to  develop  the  Mission  Need  Statement. 
The  first  step  is  the  assignment  of  an  Action  Officer  who  is  responsible  for  the  Mission  Need 
Statement.  Each  of  the  additional  steps  in  the  process  (which  correspond  roughly  with  organizations) 
has  the  ability  to  make  comments  and  stop  the  validation  and  approval  of  the  MNS  until  they  are 
resolved.  The  next  step  in  the  process  is  to  write  a  draft  MNS  that  is  then  staffed  internally  to 
NORAD  for  comments  and  review.  Once  those  comments  have  been  consolidated  and  resolved,  the 
draft  MNS  is  sent  before  a  NORAD  review  board.  Once  approved,  the  MNS  is  sent  to  the  Military 
Cooperation  Committee  between  the  US  and  Canada.  When  there  are  no  issues  preventing  it  from 
further  development,  the  MNS  is  sent  into  the  different  approval  processes  for  the  US  Military  and  the 
Canadian  Military.  On  the  US  side,  the  Joint  Requirements  Oversight  Committee  (IROC)  and  joint 
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staff  distributes  the  MNS  to  each  of  the  services  and  the  Commander  in  Chiefs  (CINCs).  (It  is  highly 
likely  that  these  players  have  already  seen  advance  copies  and/ or  drafts  during  this  entire  process). 
The  Canadian  National  Defense  HQ  staffs,  validates,  and  approves  the  document  according  to  their 
processes.  Once  both  bi-national  partners  have  validated  the  MNS,  it  is  considered  approved.  There 
is  no  official  timeline  for  this  process.  If  the  need  in  question  is  only  related  to  US  based  needs,  the 
MNS  win  go  from  the  NORAD  review  board  direaly  to  the  JROC  and  proceed  through  the  system  as 
indicated  earlier. 

Further  development  of  a  MNS  into  an  ORD  and  eventually  into  materiel  solutions  go  through  the 
different  component  services  and  commands.  For  instance,  the  AF  Space  Command  wfU  conduct  an 
AoA  along  with  the  help  of  the  Space  &  Missile  Center  (acquisition)  and  together  will  draft  the  ORD. 
The  ORD  will  be  staffed  through  the  system  as  described  for  the  7\ir  Force.  The  same  would  also  be 
tme  for  the  other  services  and  their  processes. 

Organiiatioml  hsues 

The  Organization  of  NORAD  is  unique  in  that  it  is  not  only  joint,  but  also  a  bi-national  command. 
The  dual  nationalities  lead  to  some  different  organizational  arrangements.  As  part  of  the  NORAD 
agreement,  an  American  Officer  is  always  the  CDSfC  of  NORAD.  A  Canadian  is  always  the  Vice 
CINC.  Since  NORAD  plays  such  an  important  part  for  the  National  Security  of  the  United  States,  the 
militaiy  officer  in  charge  of  NORAD,  is  also  the  Commander  of  US  Space  Command.  When  an  Air 
Force  officer  is  the  NORAD  and  US  Space  Command  CINC,  that  officer  is  also  the  Commander  of 
the  Air  Force  Space  Command.  This  arrangement  is  designed  to  prevent  organizational  barriers  from 
being  formed  among  the  different  commands.  Also,  the  same  individual  fills  most  of  the  positions  in 
each  of  the  directorates  in  NORAD  and  the  US  Space  Command.  For  instance,  this  means  the 
Director  of  Plans  is  the  same  person  for  both  NORAD  and  the  US  Space  Command. 

Business  Issues 

NORAD  only  has  a  budget  and  resources  that  directly  relate  to  its  Headquarters  Building  and  the 
Cheyenne  Mountain  Operations  Center.  The  respective  country’s  militaries  and  their  respeaive 
component  services  and  commands  physically  own  all  other  assets.  Therefore,  the  needs  of  NORAD 
can  only  be  met  when  another  organization  (a  service,  service  component,  etc.)  decides  to  acquire  the 
capability  advocated  by  the  Integrated  Priority  List  (IPL)  and/ or  Mission  Need  Statement  (MNS). 
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Summary 

The  process  in  use  has  some  comparisons  with  the  idealized  framework.  It  begins  with  an  activity  that 
gathers  inputs  to  the  process.  Cross-funaional  teams  organize  them  and  put  them  into  context  during 
this  gathering. 
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Figure  62.  NORAD  Front-end  Process  in  Terms  of  the  Framework 

A  single  committee  does  most  of  the  consolidation  work  and  preparation  of  the  general  requirements 
for  the  organization.  This  is  in  essence  a  screening  process.  Upon  completion  of  this  first  screen,  a 
second  committee  of  more  senior  individuals  reviews  the  material.  This  committee  consists  of  the 
second  screen.  As  the  needs  identified  are  selected  to  be  developed  into  Mission  Need  Statements, 
these  same  committees  review  these  statements.  The  same  occurs  during  the  development  of  the  IPL, 
although  there  is  a  more  formal  and  stmctured  wary  for  participation  in  the  development  of  this  Hst. 
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Finally,  the  last  screen  is  an  implicit  one  that  occurs  as  the  MNS  seeks  the  sponsorship  of  another 
organization  to  conduct  further  analysis  on  the  need  and  develop  an  operational  requirements 
document.  The  screening  occurs  as  a  MNS  is  picked  up  for  development  or  not. 

US  Space  Command 

This  command  is  a  unified  command  of  all  four  US  military  services.  It  is  responsible  for  worldwide 
United  States  Space  Assets  and  their  operation.  In  addition,  NORAD  is  one  of  its  chief  customers. 

It  has  a  formal  front-end  process.  The  following  diagram  indicates  the  overall  process  flow  that  exists 
and  will  be  followed  by  more  detailed  information  about  the  process. 


Figure  63.  USSPACECOM  Planning  and  Requirements  System 
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The  system  process  internal  to  USSPACECOM  produces  several  items  that  facilitate  getting  the  final 
produrt  or  capability  to  the  warfighter.  Among  these  are  the  Vision  for  the  Command,  the  Long 
Range  Plan  (which  contains  many  of  the  Operational  Concepts  for  the  command),  a  Long-range 
Action  Plan,  Master  Plans,  Roadmaps,  Integrated  Priority  List  (IPL),  Program  Objective 
Memorandum  (POM)  inputs,  as  well  as  Mission  Need  Statements,  and  Operational  Requirement 
Documents.  All  of  these  are  produced  as  a  part  of  the  process. 

The  overall  process  is  planned,  controlled  and  executed  by  one  organization,  J-5,  the  Directorate  of 
Planning.  The  J-5  is  a  one-star  position  at  USSPACECOM.  The  process  is  continually  artive.  It  is 
not  strictly  serial  in  its  operations.  The  vision  for  the  command  is  updated  yearly,  and  the  Long  Range 
Plan  is  updated  twice  a  year.  The  Roadmaps  are  updated  continuously  to  maintain  their  six-year  look. 

The  following  diagram  outlines  the  organization  outlook  of  the  process.  Each  product  of  the  process 
goes  through  the  process  flow  outlined.  Detailed  explanation  will  follow  in  subsequent  paragraphs. 
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Figure  64.  USSPACECOM  Organizational  Process  Flow 

USSPACECOM  has  identified  11  Mission  Areas  that  it  is  responsible  for.  These  are  things  like  Space 
Control,  Navigation,  Warning  and  Assessment,  Meteorological  and  Oceanographic,  Communications, 
Reconnaissance  and  Surveillance,  Force  Application,  Spacelift,  Earth  Resource  Monitoring,  Command 
and  Control,  and  Satellite  Operations.  The  11  Mission  Area  Teams  (MATs)  are  used  to  provide  in- 
depth  support  and  expertise  to  the  Mission  Area  Point  of  Contact  (POC).  The  POC  is  expected  to  be 
the  funaional  expert  in  the  particular  mission  area  and  provide  detailed  information  on  capabilities, 
CONOPs  and  organizations  as  well  as  systems,  technologies  and  partnerships  required  to  achieve 
specified  objectives  of  the  Long  Range  Plan  operational  concepts.  The  Working  Group  (WG)  is  also 
used  for  detailed  information  to  build  the  vision,  and  long  range  plan.  After  it  is  built,  the  group 
constantly  probes  the  understanding  of  the  group  members  to  develop  other  mission  needs,  further 
develop  deficiencies,  and  missing  capability. 
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The  Operational  Concept  Champions  (OCC)  are  responsible  for  actually  writing  the  Long  Rang  Plan. 
Additionally,  they  write  the  Long  Range  Aaion  Plan  semi-annually  outlining  what  steps  need  to  be 
taken  to  implement  the  Long  Range  Plan  (LRP)  as  much  as  possible  within  the  next  six  years.  The 
OCCs  update  the  vision  and  manage  the  updates  of  the  LRP  as  required,  and  ensure  that  appropriate 
products  are  produced  -  like  the  IPL,  Requirements  Documents,  etc.  (The  service  components  are  to 
be  the  primary  data  provider  for  development  of  the  Six-Year  Roadmaps  and  system  and  technology 
inputs.)  The  OCCs  chair  four  working  groups.  These  working  groups  are  made  up  of  all  of  the 
Mission  Areas  POCs  and  a  matrixed  cross-representation  of  personnel  from  the  directorate, 
component,  and  other  agencies. 

Shortfalls  are  identified  by  the  OCCs  as  they  continuously  update  the  six-year  roadmaps  and  identify 
proposed  changes/updates  to  the  LRP.  This  also  includes  identifying  other  shortfalls  against 
identified  requirements  from  other  sources  such  as  other  Lfnifled  CINCs.  AJl  of  these  shortfalls  are 
then  prioritized  and  consolidated  with  the  help  of  the  common  IT  database  and  decision  assistance 
tool  known  as  the  Automated  Database  and  Expert  Planning  Tool  (ADEPT).  The  information 
contained  in  the  tool  forms  the  basis  for  IPL  development. 

The  Integrated  Assessment  Working  Group  (lAWG)  actually  develops  the  draft  IPL.  Additionally,  the 
lAWG  integrates  and  provides  guidance  to  the  OCC  Working  Groups  and  reviews  all  of  the  products 
of  the  Planning  and  Requirements  System.  The  members  of  the  LAWG  are  all  of  the  OCC  Chairs, 
component  representatives,  and  other  designated  personnel.  Comments  are  collected  and  resolved. 
Then  it  is  sent  before  the  Flag  Officer  Steering  Group  (FOSG).  The  FOSG  provides  top-level 
guidance  to  the  overall  planning  and  requirements  process,  reviews  issues  and  recommendations  and 
provides  guidance  on  the  final  LRP  and  IPL.  The  members  of  this  group  are  all  of  the 
USSPACECOM  Direaors  (they  can  be  of  differing  rank  (as  low  as  Colonel  and  as  high  as  2-star 
general)  depending  upon  importance  to  the  command)  and  the  component  commanders.  The  Deputy 
commander  of  USSPACECOM  chairs  the  FOSG.  Comments  are  collected  and  resolved.  The  CINC 
of  USSPACECOM  then  approves  the  document,  either  the  LRP  or  IPL. 

As  far  as  requirements  document  development  is  concerned,  the  Mission  Area  POCs  are  responsible 
for  identifying  the  Requirements  Documents  needed  to  address  the  identified  shortfalls.  They  will  also 
recommend  either  USSPACECOM  or  one  of  the  components  to  develop  the  document.  They  will 
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draft  recommended  completion  timelines  that  address  the  shortfall(s)  of  their  mission  element.  A 
MNS  that  USSPACECOM  decides  to  draft  will  follow  the  exact  same  process  followed  by  the  IPL 
and  LRP  development  except  that  the  lAWG  members  and  FOSG  members  coordinate  individually 
(no  meetings  are  called)  before  the  document  is  signed  by  the  CINC.  Then  the  MNS  enters  the  Joint 
Requirements  Process  controlled  by  the  Joint  Requirements  Oversight  Council  (JROC)  for  further 
action.  USSPAGECOM  is  able  to  draft  a  MNS  but  not  able  to  pursue  a  requirement  further  (conduct 
an  Analysis  of  Alternatives  (AoA)  or  build  an  Operational  Requirement  Document  (ORD)).  It  reUes 
upon  one  of  the  service  components  to  accept  the  deficiency,  implement  a  solution  or  system  to 
address  the  deficiency,  as  well  as  pay  for  program  to  correct  the  deficiency. 

The  Director  of  Plans,  J-5,  is  also  charged  to  review  all  POM  documents.  Budget  Estimate 
Submissions  (BES)  and  other  PPBS  documents  to  ensure  consistency  with  the  requirements  outlined 
by  USSPACECOM  to  include  the  PPBS  documents  of  the  components,  particularly  to  ensure  the 
components  are  supporting  the  IPL. 

OrganiTatumd  Issues 

The  organization  is  setup  such  that  one  single  Directorate  is  responsible  for  the  entire  front-end  to 
include  advocating  proper  resource  allocation  in  their  components’  PPBS  process.  The  size  of  this 
organization  doing  aU  of  this  work  is  rather  small.  Since  this  organization  is  also  functioning  as  the 
NORAD  J-5,  it  does  condua  the  PPBS  functions  for  NORAD’s  relatively  small  PPBS  inputs. 

The  existence  of  four  screening  functions  is  remarkable  in  terms  of  the  idealized  framework.  The 
product  development  space  that  the  USSPACECOM  process  operates  in  is  roughly  that  of  the  first 
two  stages.  Additionally,  it  is  evident  that  many  of  the  organizational  structures  overlap  those  of  the 
component  commands  that  attempt  to  do  the  same  things. 

Another  interesting  organizational  fact  is  that  when  the  Air  Force  is  commanding  USSPACECOM,  it 
is  also  commanding  the  Air  Force  Space  Command.  Not  surprisingly,  the  AF  Space  Command  has 
many  processes  that  are  similar  in  nature  to  those  found  in  USSPACECOM.  However,  another 
interesting  feature  is  that  there  are  times  when  the  USSPACECOM  CINC  has  to  direa  the 
AFSPACECOM  CESfC  to  do  something  and  they  simply  agree  to  disagree.  "The  letter  is  signed  twice 
by  one  person  wearing  two  hats  reaching  differing  conclusions." 
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Business  Issues 

SPACECOM  has  an  integrated,  sophisticated  information  technology  tool.  This  tool  is  called  the 
Automated  Database  and  Expert  Planning  Tool  (ADEPT).  It  is  used  to  automate  the  Long  Range 
Plan.  This  same  tool  contains  an  advanced  decision  making  assistant  tool  that  is  used  for  decisions 
relating  to  prioritizing  deficiencies  and  capability  shortfalls.  This  tool  is  the  foundation  for  the 
development  of  the  IPL  and  all  other  products  of  the  Space  Planning  and  Requirements  Process. 

Summary 

The  USSPACECOM  process  is  well  thought  out  in  terms  of  explicitly  linking  planning  with 
requirements.  Additionally,  the  use  of  the  ADEPT  tool  is  by  far  the  most  sophisticated  tool  in  use  by 
the  Air  Force  today.  The  use  of  the  tool  allows  four  screening  processes  to  occur  twice  a  year  or  even 
more  frequently  as  occasion  requires.  Other  services  or  unified  commands  with  similar  screening 
structures  are  not  as  agile  in  their  process  flow  capability. 
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Figure  65.  USSPACECOM  Front-end  in  Terms  of  the  Framework 


This  process  is  also  mature  because  it  allows  for  and  even  expects  multiple  sources  of  needs  and 
requirements.  However,  it  seems  unable  to  guarantee  the  approved  needs  will  get  the  funding  it 
requires  for  further  development.  This  is  strictfy^  the  result  of  the  process  being  split  between  the 
unified  commands  and  the  service  components.  This  split  allows  a  service  component  to  further  its 
own  unique  goals  and  objectives  that  are  separate  from  those  of  the  unified  command  they  support. 
Although  the  joint  leadership  should  dissuade  this  from  happening,  it  does  not  according  to 
interviewed  sources. 
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CHAPTER  7  -  OVERALL  DATA  ANALYSIS 


Each  of  the  case  studies  was  scored  using  the  Maturity  Matrix.  The  relationships  to  the  idealized 
framework  have  already  been  made  in  the  case  study  writings.  This  chapter  indicates  the  relative 
performance  of  each  organization  in  relation  to  the  Process  Mamrity  Matrix  contained  in  the 
framework. 

Discussion 

As  the  framework  asserts  that  Organizational  and  Business  Enablers  are  required  for  an  advanced 
front-end,  and  that  this  advanced  front-end  demonstrates  characteristics  that  are  desirable;  it  is 
hypothesized  that  the  enablers  will  be  positively  correlated  with  each  stage  of  the  framework  as  well  as 
with  the  overall  process. 

The  coded  data  from  the  maturity  matrix  was  evaluated  according  to  its  correlation  coefficient  and  its 
confidence  factor.  Correlation  analysis  measures  the  strength  of  relationship  between  two  variables.  A 
positive  correlation  indicates  that  large  values  of  one  variable  are  associated  with  large  values  of  the 
other  variable.  A  negative  correlation  indicates  that  lai^e  values  of  one  variable  are  associated  with 
small  values  of  the  other  variable.  If  a  positive  correlation  exists,  it  does  not  mean  that  one  variable 
causes  the  other  variable.  Although  there  may  be  a  causal  link  between  the  two  variables,  the  measure 
of  correlation  does  not  prove  a  link  exists.  The  confidence  factor  indicates  the  level  of  confidence  (the 
probability)  in  the  outcomes  of  the  data  analysis  (or  that  the  data  is  in  fact  correlated). 

One  correlation  test  statistic  is  the  Pearson  product  moment  correlation  coefficient,  or  r.  It  is  a 
dimensionless  index  that  ranges  from  -1.0  to  1.0  and  reflects  the  extent  of  a  linear  relationship  between 
two  variables.  R-squared  is  the  proportion  of  the  variance  in  y  attributable  to  the  variance  in  x. 

The  r  measures  assume  a  normal  shaped  distribution  of  the  data.  Due  to  the  small  sample  size, 
however,  normality  of  this  data  is  difficult  to  determine.  One  method  is  to  look  at  a  histogram  of  the 
data  and  see  how  it  might  compare  to  a  normal  shaped  curve.  For  example,  the  data  for  the 
Identification  of  Requirements  Phase  can  be  represented  as  a  histogram  in  this  fashion.  All  of  the 
variables  were  examined  in  this  manner. 
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Figure  66.  Identification  of  Requirements  Phase  Data  Histogram 

While  the  majority  of  the  data  lies  at  the  center  of  the  curve,  it  has  several  outliers  (pieces  of  data  that 
don't  seem  to  belong)  that  question  the  proper  relationship  as  a  normal  distribution.  Another 
representation  of  this  information  is  to  plot  the  relationship  between  the  values  of  the  data  and  the 
normal  quartHe.  A  normal  data  set  will  approximate  a  straight  line.  The  following  graph,  using  the 
Concept  Phase  data,  is  shown  below. 


Concept 


Figure  67.  Concept  Phase  Outcomes  vs.  a  Normalized  Line 
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As  can  be  seen,  the  data  is  spread  across  the  normal  line  plot,  and  if  a  line  were  drawn  connecting  the 
data  points,  that  line  would  approximate  a  straight  line.  These  tests  were  done  for  every  variable  and 
each  of  them  displayed  similar  results  to  Figures  66  and  67.  Therefore,  using  this  analysis,  a  normal 
distribution  of  the  data  is  assumed. 

Findings 

The  data  scored  in  the  maturity  matrix  was  separated  into  the  different  phases  and  enablers.  The 
scores  for  each  of  the  elements  in  each  phase  and  enabler  were  summed  then  scaled  to  a  four-point 
scale.  The  following  charts  graphically  indicate  the  outcomes  of  the  different  phases  of  the  maturity 
matrix.  They  are  ordered  from  lowest  score  to  highest  score  among  the  different  organizations. 

The  Identification  of  Requirements  Phase  Average  Maturity  Score  for  each  organization  is  displayed  in 
Figure  68. 
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Figure  68.  Identification  of  Requirements  Phase  Outcomes 
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Figure  68  shows  that  most  commercial  companies  have  much  more  mature  requirements  identification 
processes,  while  militaiy  organizations  show  more  room  for  process  improvement.  The  Navy  and  US 
Air  Force  have  the  least  mature  processes  in  this  area.  Part  of  this  reflects  the  organizational  structure 
in  place  that  is  used  to  identify  requirements.  The  Planning  processes  for  both  of  these  services  are 
relatively  disconnected  from  the  actual  process  used  to  develop  the  documentation  for  the  later  phases 
of  the  front-end  process. 

Figure  69  displays  the  overall  process  maturity  for  the  Initial  Screening  phase  of  the  front-end. 
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Figure  69.  Initial  Screening  Phase  Outcomes 


Again,  the  outcome  of  this  phase  reflects  the  overall  division  of  process  maturity  between  the 
commercial  industiy  and  the  military.  Among  the  most  decisive  factors  in  this  area  are  the  control  and 
distribution  of  resources  for  further  development.  Most  military  organizations  are  completely 
dependent  upon  other  organizations  within  those  military  services  or  commands  to  release  funding  as 
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well  as  obtain  permission  to  proceed  into  further  concept  development  of  the  need  or  idea.  None  of 
the  commercial  companies  or  the  French  Acquisition  System  have  these  barriers  in  place. 
Consequently,  their  processes  reflect  much  more  maturity. 

Additionally,  the  contributing  factors  to  this  phase  represent  linkages  with  other  processes  such  as 
technology  development  and  other  projects  currently  being  developed  (i.e.  portfolio  management). 
Understanding  the  consequences  of  proper  risk  management  in  the  early  stages  of  development  also 
plays  a  key  role.  Again,  in  all  of  these  areas,  commercial  industry  reflects  more  process  maturity  than 
do  the  military  organizations. 

The  Figure  70  displays  the  concept  development  phase. 
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Figure  70.  Concept  Development  Phase  Outcomes 
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Concept  development  is  not  conducted  by  three  of  the  unified  commands,  as  reflected  above. 
Nevertheless,  the  militaiy  and  commercial  industry  have  reasonably  developed  concept  development 
processes,  with  the  commercial  industry  usually  having  more  mature  processes  than  the  US  Militaiy. 
One  of  the  phase  elements  that  contributed  to  the  lower  process  maturity  ranking  for  the  military  was 
the  kind  of  requirements  prioritization  that  is  done.  More  mature  processes  identify  and  prioritize 
requirements  not  only  into  ‘must  have’  and  ‘nice  to  have’  categories,  but  also  within  those  categories. 
Furthermore,  the  military  system  is  not  designed  to  accommodate  the  presence  of  requirements  that 
‘delight’  the  customer  and  are  usually  not  communicated  by  the  originator  of  the  need  or  requirement. 

The  Business  Case  Development  Phase  in  displayed  in  Figure  71. 
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Figure  71.  Business  Case  Development  Phase  Outcomes 

Again,  in  this  phase  three  of  the  Unified  Commands  do  not  participate  and  are  not  reflected  in  this 
graph.  Also,  the  militaiy  business  case  development  processes’  level  of  maturity  is  usually  less  than 
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that  of  most  commercial  companies.  Company  F’s  level  of  maturity  is  no  worse  than  the  level  of 
maturity  of  any  of  the  military  processes.  This  may  reflect  Company  F’s  close  ties  to  the  overall  front- 
end  process  within  the  militaiy.  Company  F’s  business  cases  are  dependent  upon  the  military’s 
determination  to  pursue  development  of  a  need  or  requirement. 

The  items  that  differentiate  the  outcomes  in  the  business  case  development  process  phase  are 
attributable  to  the  allocation  and  dispersion  of  resources  to  proceed  into  the  regular  new  product 
development  process  and  their  linkages  to  other  development  projects  as  well  as  linkages  to  necessary 
or  required  technology  development  processes.  The  military  processes  have  mechanisms  in  place  for 
these  things  to  occur,  such  as  using  a  Milestone  Decision  Authority  to  ensure  the  linkages  are  in  place, 
however,  the  military’s  processes  do  not  reflect  the  maturity  of  those  mechanisms  in  place  for 
commercial  companies. 

The  performance  of  the  overall  front-end  process  is  refleaed  in  Figure  72. 
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Figure  72.  Overall  Process  Outcomes 


This  graph  represents  the  overall  process  maturity  of  all  four  phases  of  the  front-end  process. 
Typically,  commercial  organizations  outperfonn  the  military  in  terms  of  process  maturity.  The  Army, 
the  Marine  Corps,  and  USJFCOM  seem  to  have  the  most  mature  front-end  processes  of  the  US 
Mditaiy  organizations.  These  outcomes  should  not  be  surprising  after  reviewing  the  individual 
outcomes  of  each  of  the  front-end  process  phases'**.  The  Army  and  Marine  Corps  do  not  separate 
Mission  Area  Analysis  or  Mission  Needs  Analysis  from  the  Requirements  Process.  They  are  viewed  as 
an  integral  part  of  the  process  (whereas  the  Navy  and  Air  Force  view  them  separately).  Additionally, 
both  services  use  a  team  to  develop  their  needs  and  requirements.  Finally,  both  services  use  a  formal 
process  to  prioritize  their  needs  and  requirements  prior  to  entering  the  PPBS  process  (the  Warfighting 
Lens  Analysis  (WFLA)  process).  USJFCOM  benefits  from  the  overall  influence  of  the  Army  and 
Marine  Corps;  in  addition,  the  Air  Force  component  (Air  Combat  Command)  uses  a  similar  formal 
prioritization  scheme  (the  Modernization  Investment  Plan  (MIP)  for  its  needs  and  requirements.  US 
Space  Command  and  the  Air  Force  Space  Command  also  have  a  formal  method  to  prioritize 
requirements  (the  ADEPT  process),  however,  the  Air  Force  stiU  separates  the  Need  generation  and 
Requirement  generation  processes. 

The  Organizational  and  Business  Enablers  are  indicated  below.  Figure  73  is  of  the  Organizational 
Enablers. 


For  overall  process  maturity  ranking,  the  three  unified  commands  that  did  not  contribute  to  the  concept  development  and  business  case 
development  phases,  were  given  relative  scores  in  those  areas  reflecting  the  primary  service’s  input  to  that  area.  For  example, 
USJFCOM  was  given  the  average  score  of  the  four  services  in  each  phase,  while  NORAD  and  US  Space  Command  were  given  the  US 
Air  Force  scores  for  those  process  phases. 
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Organizational  Enablers 
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Figure  73.  Organizational  Enablers  Outcomes 

Every  organization  has  achieved  a  fair  level  of  organizational  maturity.  There  are  significant 
differences  between  the  performance  of  military  and  commercial  organizations  in  using  organizational 
enablers.  The  average  military  organization  is  about  Vi  as  good  as  the  best  commercial  organization. 
Most  of  these  differences  are  based  upon  the  organizational  structure  used  for  the  front-end  process. 
The  most  mature  organizations  typically  are  team-based  and  draw  members  from  a  variety  of  cross¬ 
functional  disciplines  and  other  organizations  with  the  enterprise  to  build  front-end  teams. 

The  Figure  74  displays  the  Business  Foundation  enabler  outcomes. 
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Figure  74.  Business  Enablers  Outcomes 

Business  Enablers  show  distinct  differences  between  the  maturity  of  military  organizations  and 
commercial  organizations,  similar  to  that  shown  in  the  Organizational  Enablers  outcomes.  Typically, 
the  differences  among  the  Business  Enablers  are  highlighted  in  the  separation  between  the 
‘requirements  approval  process’  and  the  ‘resource  allocation  process’  in  the  military.  Commercial 
organizations  make  no  such  separation;  they  are  tightly  integrated  functions.  Furthermore,  the 
presence  of  an  Information  Technology  tool  that  not  only  traces  the  development  of  the  requirements 
but  also  includes  decision  aides  and  methodologies  for  all  phases  of  the  front-end  process 
distinguishes  a  highly  mature  process.  There  are  Islands  of  Excellence  within  some  of  the  Military 
Services  and  also  US  Space  Command  uses  such  a  tool  in  their  front-end  process;  however,  as  US 
Space  Command  does  not  participate  in  all  of  the  process  phases,  the  tool’s  contribution  to  its  overall 
process  performance  is  muted. 
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Discussion 

One  of  the  hypotheses  was  that  there  would  be  a  correlation  between  the  process  maturity  of  the 
Enablers  and  Enabling  Practices  to  the  front-end  process  outcome.  Actual  outcome  measures,  such  as 
those  of  the  previously  identified  metrics,  to  verily  the  validity  of  the  front-end  process,  were  not 
available  for  analysis.  In  some  cases,  there  were  no  such  metrics  in  place.  This  was  particularly  tme 
for  the  mditaiy  processes. 

The  Table  16  displays  the  correlation  coefficients  between  the  different  phases  of  the  matrix  vs.  those 
enabling  practices  and  the  p- value  associated  with  the  correlation  coefficient.  A  p-value  less  than  0.05 
is  generally  considered  significant.  Computed  at  the  95%  confidence  level,  a  p-value  less  than  0.05 
indicates  at  least  a  95%  level  of  confidence  (or  higher)  in  the  statistic  being  computed.  Due  to  the 
small  sample  size,  a  p-value  less  than  0. 1  will  be  considered  significant  in  these  cases.  The  results  in 
Table  16  show  that  all  of  the  process  phases  are  strongly  correlated. 


Process  Phase 

Organi 

Ena 

zational 

jlers 

Business  Enablers 

Overall  Enablers 

Gsirelation 

Coefficient 

p-value 

Correlation 

Coefficient 

p-value 

Correlation 

Coefficient 

p-value 

Identification  of 
Requirements  Phase 

0.69 

0.0022 

0.66 

0.0038 

0.68 

0.0024 

Initial  Screening 
Phase 

0.74 

0.0008 

0.83 

<0.0001 

0.79 

0.0002 

Concept 

Development  Phase 

0.68 

0.0027 

0.68 

0.0025 

0.69 

0.0022 

Business  Case 
Development  Phase 

0.64 

0.0061 

0.67 

0.0033 

0.66 

0.0040 

Overall  Process 

0.77 

0.0003 

0.81 

<0.0001 

0.80 

0.0001 

Table  16.  Correlation  Coefficients  and  Their  Respective  p-values  Among  the  Different 


Maturity  Matrix  Phases  and  Enablers 

A  closer  look  at  the  data  reveals  the  existence  of  several  data  outliers  in  the  Concept  Development 
Phase  and  the  Business  Case  Development  Phase.  First,  Company  D  consistently  performs  very  well 
in  the  individual  phases  of  the  front-end  process.  However,  the  company  performs  well  despite  lower 
process  maturity  among  the  Organizational  and  Business  Enablers.  The  result  is  this  company  is  a 
consistent  outlier  among  the  correlation  data.  Furthermore,  this  company  is  a  software  company.  It  is 
the  only  company  with  this  profile.  Further  research  should  investigate  if  different  types  of  industries 
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perform  differently  against  the  idealized  front-end  process  and  corresponding  maturity  matrix.  Also, 
Companies  G  and  H  are  in  close  proximity  to  company  D.  These  two  companies  are  from  a  different 
industry  than  Company  D,  but  they  are  in  the  same  industry  among  themselves,  the  airlines.  Again, 
this  prompts  the  question  of  whether  an  industry  performs  differently  in  relation  to  the  maturity 
matrix  and  reveals  a  different  type  of  response  profile  to  the  front-end  process  framework  and 
maturity  matrix. 

The  following  charts  present  a  closer  look  at  the  relationship  between  the  iadividual  portions  of  the 
maturity  matrix  and  the  enablers.  Table  16  shows  that  there  was  virtually  no  difference  in  correlation 
between  the  Business  Enablers  and  Organizational  Enablers.  Therefore,  all  of  the  following  charts  will 
use  the  Overall  Average  Enabler  Scores.  Not  every  pairing  of  process  phases  and  enablers  will  be 
given;  only  those  that  can  provide  additional  insight  beyond  the  statistical  correlation  information  in 
the  table  above  are  shown. 
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Identification  of  Requirements  Phase  vs.  Average  Enablers 
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Figure  75.  Outcome  of  Identification  of  Requirements  Phase  vs. 

Organizational  Enablers 

This  figure  is  shown  because  it  illustrates  the  process  shortcomings  of  two  US  Military  Services.  In 
both  of  these  cases,  the  Navy  and  the  US  Air  Force  have  a  process  that  is  much  less  mature  than  those 
of  the  other  services  or  military  organizations.  In  both  cases,  the  front-end  is  disconnected  between 
the  planning  funaion  of  these  organizations  (where  needs  and/ or  requirements  are  initially  identified) 
and  their  movement  forward  through  the  rest  of  the  front-end  process.  The  French  have 
disconnected  data  as  well.  The  explanation  for  the  discrepancy  lies  in  the  way  that  it  gathers  needs  and 
requirements  -  it  relies  heavily  upon  its  customers  (the  warfighters)  and  the  solutions  are  typically 
crafted  in  terms  of  a  specific  solution  already  envisioned  by  their  customer.  Company  C  is  among  the 
best  performers  in  most  process  areas,  in  this  case,  the  methods  used  to  identify  needs  and 
requirements  are  not  as  mature  as  they  potentially  have  the  capability  to  be  because  the  company  relies 
upon  the  marketing  department  for  its  front-end  inputs  and  closes  out  the  possibility  of  other  cross¬ 
functional  inputs. 
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The  Figure  76  shows  the  relationship  between  the  Screening  Phase  and  the  Average  Enablers. 
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Figure  76.  Outcomes  of  Screening  Phase  vs.  Organizational  Enablers 

Figure  76  clearly  shows  that  the  current  screening  phase  in  the  militaiy  front-end  process  is  less  mature 
than  commercial  counterparts  (a  fart  underscored  by  the  length  of  the  current  Air  Force  Process  for 
the  screening  stage  of  over  400  days).  The  common  traits  of  long  cycle  time  and  multiple  level  reviews 
is  typical  of  all  military  organizations,  with  the  exception  of  the  French  Procurement  Agency. 
Additionally,  there  are  many  needs  approved,  but  no  resources  allocated  for  their  approval.  In  some 
sense,  this  stage  in  the  military  process  really  isn’t  an  initial  screen  at  all;  it  is  primarily  a  consensus 
building  exercise  (albeit  time  consuming  and  expensive). 

Company  C’s  response  reflects  less  process  maturity  due  to  the  uncertainty  involved  in  finding 
resources  to  further  develop  a  need  during  the  concept  development  phase.  Company  D  has  virtually 
no  formal  screen  at  all;  certainly,  it  is  not  a  formal  process.  Nevertheless,  the  company’s  stmcture 
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gives  tremendous  flexibility  within  general  guidance  to  first-level  employee  supervisors  that  overcome 
its  less  mature  organizational  and  business  processes.  Company  B’s  disconnect  comes  from  separate 
processes  having  a  piece  of  this  phase.  Company  G’s  disconnect  comes  from  having  just  one 
organization  responsible  for  the  front-end  process  except  for  the  business  case  development  phase. 
The  company’s  performance  in  this  phase  is  better  than  its  overall  organizational  and  business  process 
enablers  would  suggest  due  to  that  reason. 

Reojnmendatkm  far  Further  Research 

Further  research  into  this  topic  will  help  further  the  understanding  and  importance  of  the  front-end  of 
product  development.  There  are  several  areas  concerning  the  front-end  process  that  have  been 
touched  upon  only  lightly  and  should  be  investigated  more  thoroughly. 

One  of  the  most  important  items  for  further  research  would  be  to  assess  the  framework  and  the 
maturity  matrix  with  outcome  measures,  including  those  referenced  within  the  Idealized  Framework. 
These  objectives  will  likely  be  very  difficult  to  achieve,  especially  in  terms  of  the  military  and  the  huge 
time  period  required  to  navigate  the  front-end  process.  This  difficulty  is  further  compounded  by  the 
‘lack  of  definition’  of  many  of  the  projects  that  undergo  several  iterations  and  name  changes  before 
moving  on  within  the  process.  Among  commercial  companies,  outcome  information  should  be  much 
easier  to  obtain  as  many  of  the  identified  metrics  and  process  controls  are  already  in  place.  Significant 
literature  also  exists  on  the  performance  of  the  front-end  tying  measures  to  existing  organizational 
performance. 

An  additional  step  for  further  research  would  be  to  expand  the  sample  size  to  a  much  greater  size, 
targeting  several  industries  (to  investigate  the  possibility  of  different  industry  performance  within  the 
framework)  and  multiple  organizations.  This  study  should  try  to  determine  if  things  such  as  product 
complexity  and  technology  influence  an  organization’s  front-end  process.  Additionally,  other 
governmental  agencies  that  are  involved  in  product  development,  such  as  NASA,  the  FAA,  the  Coast 
Guard,  and  others  should  be  included  as  part  of  this  sample. 

Requirements  Management  is  a  constant  on-going  issue  with  existing  programs,  particularly  in  military 
programs  that  take  years  to  develop  and  field.  Previous  studies  have  indicated  the  importance  of  good 
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management  of  requirements,  as  they  can  contribute  significantly  to  the  cost  and  schedule  growth  that 
accompanies  many  programs. 

Another  area  of  research  is  the  notion  of  ‘Requirements  Ripple’.  This  term  can  be  defined  as  the 
effect  that  changing  one  requirement  can  have  on  the  overall  system  and  overall  system  requirements. 
This  effect  was  encountered  at  one  of  the  company  sites  during  this  research  and  the  company 
indicated  that  a  ‘simple’  requirement  change,  usually  done  at  the  request  of  a  customer,  can  and  often 
has  unwanted  and  undesirable  consequences.  The  company  expressed  interest  in  the  delivery  of  a 
notional  framework  that  would  allow  them  to  estimate  the  effect  of  requirements  changes  in  terms  of 
both  cost  and  schedule.  Such  a  produa  was  beyond  the  scope  of  this  effort,  but  one  where  the  need  is 
clearly  expressed.  The  complexity  of  developing  such  a  framework  or  tool  for  different  requirement 
types  is  not  known  or  well  understood. 

Another  area  of  interest  would  be  evaluating  the  organizational  implications  of  constant 
reorganizations  and  its  effea  upon  the  front-end  process  of  an  organization.  Company  E  practices 
this  quite  frequently,  but  the  reorganization  is  expected  and  also  a  part  of  the  company’s  culture.  The 
US  Militaiy,  on  the  other  hand,  is  also  known  for  its  constant  reorganizations.  However,  the 
performance  of  these  organizations,  in  terms  of  the  Idealized  Framework,  leaves  much  room  for 
improvement.  A  study  on  the  differences  between  these  two  examples  would  add  a  great  deal  of 
understanding  to  the  theories  behind  organizational  change. 

Another  area  of  study  would  be  to  pursue  the  cost  of  operating  a  front-end  process,  particularly  the 
screening  processes.  Recent  research  indicates  that  the  costs  of  a  front-end  process  may  actually 
outweigh  its  benefits  (Reinertsen  1999).  This  implies  the  actual  costs  of  running  the  front-end  process 
as  designed,  to  include  personnel  costs  and  research  costs,  may  actually  be  more  than  the  returns  a 
projea  might  provide  an  organization  had  there  been  no  front-end  process.  Furthermore,  this 
research  distinguishes  between  types  of  screening  processes  found  in  the  front-end.  These  screens  can 
be  extremely  tough  or  relatively  weak.  A  tough  screen  at  the  beginning  of  the  process  (and  usually  also 
the  most  expensive  to  operate),  ensures  virtually  all  projects  proceeding  from  that  point  on  are  likely  to 
make  it  to  market  (Reinertsen  1999).  A  second  situation  can  have  a  relatively  loose  initial  screening 
followed  by  an  extremely  tough  second  screen  (similar  to  the  Business  Case  Development  Phase  in  the 
Idealized  Framework).  The  variations  in  process  design  are  too  numerous  to  mention.  However, 
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measurement  of  the  outcomes  of  these  different  types  of  processes  would  contribute  greatly  to  the 
knowledge  about  the  front-end  of  product  development  and  can  lead  to  heuristics  about  when  to  use 
particular  process  designs  over  other  alternatives.  Again,  the  research  indicates  that  the  design  of  the 
front-end  needs  to  be  based  upon  economics  (the  investment  required  and  also  the  costs  to  maintain 
and  operate  verses  the  overall  returns)  (Reinertsen  1999). 

In  terms  of  the  US  Military,  it  is  difficult  to  quantify  if  its  screening  processes  are  really  screens  or  just 
methods  to  build  consensus.  Rarefy,  if  ever,  will  a  program  be  cancelled  following  successful 
navigation  of  the  overall  front-end  process  (HiU,  Jr.  et  al.  1986).  Furthermore,  the  cost  of  the  screens 
is  likely  to  be  huge  and  probably  greater  than  first  surmised.  Analysis  of  these  screens  (and  the  overall 
process  from  an  economic  point  of  view  (since  the  cost  of  delay  is  so  difficult  to  measure  in  rrulitaiy 
terms))  could  provide  even  more  compelling  information  for  the  reform  of  the  military’s  front-end 
processes. 
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CHAPTER  8  -  CONCLUSIONS 


The  overall  objective  of  this  thesis,  to  find  Best  Practices  for  the  front-end  of  produa  development 
through  observation  and  correlation,  has  been  addressed.  These  practices  have  been  organized  and 
presented  in  a  framework  of  Best  Practices  for  the  Front-end  of  Product  Development.  A  hypothesis 
throughout  this  thesis  is  that  organizational  and  business  enablers  are  required  for  an  advanced  front- 
end  of  product  development.  This  hypothesis  has  been  supported  by  the  correlation  between  the 
Process  Enablers  and  the  Best  Practices  outlined  in  the  front-end  framework  and  maturity  matrix. 
The  framework  and  matrix  is  not  all-inclusive;  rather,  it  is  hoped  that  the  framework  will  provide 
organizations  a  starting  point  to  better  understand  their  front-end  processes,  their  process 
performance,  and  ultimately  their  process  outcomes.  Furthermore,  it  is  the  author’s  wishes  that  the 
framework  be  considered  a  work  in  progress,  awaiting  the  addition  of  further  process  knowledge,  best 
practices,  and  understanding,  whether  gained  through  academic  literature  or  actual  experimentation. 

This  work  began  by  illustrating  some  of  the  challenges  and  problems  facing  the  US  Air  Force  in 
developing  needs  and  requirements  for  weapon  systems.  There  are  many  issues  that  are  probably 
coupled  with  politics  and  other  factors  outside  of  the  control  of  the  Air  Force,  but  the  discussion  in 
this  work  focused  upon  those  issues  that  most  likely  had  a  root  cause  in  the  process  of  developing 
needs  and  requirements;  one  that  is  not  suited  for  today’s  environment.  Clearly  this  observation  is 
evidenced  by  the  calls  for  reform  and  changes  of  these  systems  from  within  the  services  themselves 
and  the  commissioning  of  efforts  to  reform  the  existing  systems. 

The  front-end  process  of  the  US  Air  Force  and  the  US  Military  overall  is  similar  to  the  current  efforts 
of  commercial  firms  to  develop  produas  quickly  and  effeaively.  This  analogy  allowed  for  the 
comparison  of  product  development  processes  with  the  processes  used  in  the  militaiy.  Focusing  upon 
the  very  initial  stages  of  product  development,  this  ‘front-end’  was  analogous  to  the  purposes  of  the 
planning  and  requirements  processes  of  the  US  Militaiy.  The  existing  literature  was  probed  for 
additional  information  regarding  the  front-ends  of  both  the  military  and  commercial  processes  in  order 
to  quantify  and  bound  the  area  of  interest.  The  various  appendicies  are  designed  to  give  greater  depth 
and  understanding  about  topics  that  are  secondary  to  the  purpose  of  this  work,  but  highly  relevant  to 
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the  overall  understanding  of  the  front-end  process.  To  achieve  the  holistic  perspective  of  the  front- 
end,  this  information  was  added. 

Highlighting  the  importance  of  the  Front-end  of  product  development,  this  work  provides  an 
organized  framework  to  objectively  quantify  the  essential  elements  of  a  front-end  process.  The  front- 
end  can  be  organized  into  a  very  successful  and  orderly  process  by  which  organizations  can  achieve 
substantial  returns,  both  in  terms  of  saved  resources,  but  also  great  new  products  that  serve  the  needs 
of  its  customers.  The  framework  expounds  upon  the  relevant  literature  and  adds  process  metrics  that 
will  quantify  performance  of  an  organization’s  front-end.  Additionally,  the  elements  of  the  front-end 
process  have  been  arranged  in  a  matrix  form  to  allow  an  organization  to  measure  its  relative  process 
performance  and  identify  areas  to  focus  its  improvement  efforts. 

The  applicability  of  the  framework  was  demonstrated  by  examining  seventeen  organizations,  nine 
military  organizations  and  eight  commercial  organizations.  The  military  organizations  came  from 
every  service,  a  representative  combination  of  forces  embodied  in  three  unified  commands,  and  also  a 
foreign  military  example.  This  combination  was  to  sample  the  various  ways  to  approach  the  front-end 
in  the  military.  On  the  commercial  side,  firms  from  various  high  technology  industries  to  more 
traditional  mass  production  industries  were  sampled,  along  with  firms  directly  involved  in  the 
aerospace  industry  and  the  commercial  defense  industry.  Again,  this  was  done  to  approximate  the 
wide  variation  of  practices  in  use  among  commercial  industry  today. 

Upon  review,  each  of  the  US  Military  Services  exhibited  various  “Islands  of  Excellence”  that  are 
laudable  in  their  efforts  and  views  of  holistic  thinking,  such  as  the  Army’s  use  of  the  Integrated 
Concept  Team,  the  Marine  Corps  (and  Army’s)  WFLA  process,  the  Navy’s  centralized  process  owner, 
and  the  Air  Force’s  common  IT  tool  (soon  to  be  fielded).  However,  analysis  of  the  information  shows 
all  of  these  efforts  break  down  in  the  overall  system  process  and  contribute  very  little  to  overall 
process  maturity  -  no  more  or  less  than  other  practices.  Undoubtedly  this  situation  leaves  those 
working  in  these  Islands  of  Excellence  discouraged,  particularly  when  these  practices  receive  little  or 
no  recognition  of  their  potential. 

Although  commercial  organizations  fare  on  average  much  better  than  the  military  in  process 
performance  and  on  their  application  of  enablers,  there  are  stiU  substantial  variations  in  process 
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outcomes.  Nevertheless,  the  top  performers  were  usually  commercial  organizations.  Among  the 
reasons  top  performers  fared  well  in  the  analysis  was  that  their  front-end  processes  function  according 
to  the  purposes  of  their  design  and  encounter  very  few  of  the  problems  facing  the  military.  These 
organizations  typically  have  organized  front-ends  and  are  more  holistic  in  their  approach  to  product 
development.  They  seek  to  constantly  improve  their  processes  and  place  considerable  importance  of 
the  front-end  process  on  the  future  viability  of  the  organization. 

During  the  analysis,  the  maturity  matrix  was  tested  and  the  hypotheses  about  ‘holistic’  approaches  to 
the  front-end  of  product  development  built  upon  a  solid  foundation  of  Business  and  Organizational 
enablers  were  supported.  Again,  the  results  of  this  research  only  echo  and  substantiate  what  two 
special  commissions  on  defense  have  asserted  in  the  past  about  the  importance  of  the  front-end  to  the 
military’s  overall  process  (Gregory  1989). 

The  US  Air  Force  and  other  military  organizations’  processes  perform  adequately.  The  achievements 
fostered  by  these  processes  are  relevant.  These  processes  enabled  our  country  to  win  the  Cold  War. 
Later  entanglements  in  Iraq,  Bosina,  and  Kosovo  have  underscored  the  achievements  of  the  current 
weapon  system  development  process.  However,  the  analysis  clearly  shows  these  processes  could  and 
should  be  improved.  Clear  recommendations  to  the  US  Air  Force  have  been  suggested  that,  if 
embraced,  will  likely  require  unprecedented  changes  in  organizations  and  processes.  Nevertheless,  for 
radical  process  improvement  to  occur,  these  identified  best  praaices  must  be  implemented,  as  well  as 
implementing  the  required  organizational  and  business  enablers,  as  soon  as  possible,  to  foster  the 
process  improvement. 

As  the  budget  available  for  the  US  Militaiy  declines  proportionate  to  other  areas  of  the  US  Federal 
budget,  the  message  is  more  clear  today  than  ever,  the  US  Military  must  develop  and  field  weapon 
systems  faster,  smarter,  better,  and  cheaper  than  ever  before.  Without  these  processes  and  enablers  in 
place,  the  US  Military  will  find  it  increasingly  difficult  to  maintain  the  superiority  of  arms  advantage 
over  its  adversaries  it  has  held  for  so  long. 

Eliminating  the  process  disconnects,  multiple  handoffs  and  approvals,  lack  of  authority  and  consensus 
building  rather  than  effective  decision-making  must  be  done  sooner  rather  than  later.  Currently  these 
things  represent  waste  -  wasted  time,  resources,  and  opportunity.  Building  a  systemic,  holistic  process 
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for  the  elucidation  of  needs  and  development  of  requirements  for  products  (represented  by  the  front- 
end  process  framework)  embodies  all  of  the  tenets  of  a  Lean  process  and  represents  the  future  of  the 
Air  Force. 
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Appendix  A  -  Specific  Practices  proposed  for  the  Front-end  Process 

The  following  paragraphs  will  outline  many  of  the  different  practices  espoused  in  the  technical 
literature.  The  information  presented  here  is  not  intended  to  be  all-inclusive. 

Front-end  Process  Capability  Mapping 

Khurana  and  Rosenthal  were  able  to  develop  a  classification  scheme  for  the  front-end  of  product 
development.  They  call  their  scheme  a  “front-end  capability  map”.  The  first  level  is  ‘awareness’,  the 
second  level  is  ‘islands  of  capability’,  the  third  level  is  ‘Integrated  Capability’.  In  a  sense,  this 
classification  scheme  is  similar  to  a  process  maturity  matrix.  The  levels  indicate  what  kinds  of  activities 
are  taking  place  in  each  level  and  indicate  what  activities  are  required  in  order  to  be  placed  Lq  a  higher 
process  ranking.  For  instance,  the  third  level  is  where  analysis  and  decisions  have  been  both  explicit 
and  rigorous,  and  all  front-end  activities  are  managed  as  a  single  process  (Khurana  and  Rosenthal 
1997)  49  j^cJ^eving  a  balance  between  creativity  and  discipline  is  key  to  developing  a  competence  in 
the  new  product  development  front  end  (Khurana  and  Rosenthal  1998).  Companies  using  a  'map' 
according  to  the  proposed  heuristics  can  identify  areas  for  improvement  and  concentrate  their 
resources  in  those  areas. 

The  Missed  Elevator  Approach 

A  valid  concern  of  professionals  in  the  New  Product  Development  field  is  how  keep  up  with  and 
capture  market  information  while  minimizing  changes  in  the  product  definition  in  relation  to  the  mix 
of  technology  in  the  produa.  One  study  asked  this  question  and  identified  what  is  called  the  “missed 
elevator”  approach. 

“The  program  manager  realized  that  technological  or  feature  enhancements  for  any  produa  would 
never  end.  He  required  the  produa  definition  to  include  new  features  and  feasible  solutions  to 
customer  needs,  as  long  as  the  planned  milestone  for  that  produa  release  could  be  definitely  achieved. 
If  a  customer  need  or  technology-driven  feature  “missed  the  elevator,”  it  would  go  into  the  next 
produa  release  or  “elevator.”  This  approach  to  managing  produa  development  by  having  multi¬ 
release  platform  planning  may  become  the  next  form  of  produa  development  and  management.  Not 


45  There  is  a  checklist  for  diagnosing  the  front  end  in  (Khurana  and  Rosenthal  1997). 
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only  does  it  help  achieve  a  balance  between  stability  and  flexibility,  but  it  also  leverages  technological 
strengths  and  organizational  resources”  (Khurana  and  Rosenthal  1997,  pg.  110). 

The  Nyquist  Theorem 

This  theorem  is  most  usually  associated  with  physics  and  the  technical  sciences.  Surprisingly,  an 
application  has  been  found  in  the  realm  of  new  product  development.  The  application  is  surrounding 
gathering  the  correct  information  from  a  highly  (^amic  system  that  is  undergoing  change.  A  prime 
application  of  this  is  identifying  user  needs. 

“To  recover  the  information  in  any  given  waveform,  the  sampling  rate  has  to  be  at  least  twice  the 
highest  frequency  in  the  waveform.  The  higher  the  rate  of  sampling,  the  greater  the  likelihood  of 
recovering  all  the  information.  But  the  minimum  rate  is  2  times.  Thus  if  a  company  has  a  system  that 
changes  monthly,  it  must  sample  at  least  twice  a  month  to  be  confident  that  it  is  on  top  of 
developments  within  that  system”  (Patterson  1993).  Or  if  threats  change  yearly,  monthly,  weekly, 
daily,  the  system  must  be  sampled  at  least  twice  as  often.  The  current  AF  system,  using  this  analogy, 
“samples”  yearly,  and  possibly  every  two  years,  depending  upon  the  point-of-view  (PPBS  is  a  two  year 
cycle). 

Information  Assembly  Line 

Ever  since  Hemy  Ford  introduced  the  mass  assembly  line  in  his  manufacturing  processes,  attempts 
have  been  made  to  adapt  them  to  all  kinds  of  systems.  Product  development  is  no  exception. 
Patterson  characterizes  Product  Development  as  an  Information  Assembly  line.  Just  one  extension  of 
this  thinking  allows  a  Product  Development  Process  to  be  evaluated  in  a  similar  fashion  as  the  SEI 
(Software  Enterprise  Institute)  Process  Maturity  Model.  Just  having  a  formalized  documented  process 
results  in  a  Level  3  rating.  The  information  assembly  line  can  be  seen  using  a  Value  chain’  or  ‘value 
stream’  of  processes  (Patterson  1993).  Mapping  out  process  value  streams  in  order  to  identify  process 
improvement  opportunities  is  a  generally  accepted  method  of  process  improvement.  Additionally, 
Patterson  includes  a  short  discussion  of  other  assembly  line  derivations  and  applications  such  as 
Information  Theoiy  considerations.  Operations  Management  considerations,  and  general  Management 
considerations  that  can  help  improve  a  process  (Patterson  1993). 
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Organizational  Competencies 

Rosenthal,  in  his  recent  research,  lists  seven  Organizational  Competencies  that  are  necessary  for  the 
fuzzy  front  end.  These  competencies  are  what  are  needed  to  routinely  do  successful  front-end 
analysis. 

1.  “Formulating  and  communicating  a  produa  strategy  (A  product  roadmap). 

2.  Planning  a  new-product  portfolio.  -  (Planning  competency  to  think  in  portfolio  terms.  Short-tenn 
vs.  long-term  time  frame.) 

3.  Product  approval  leadership.  -  (Leadership  should  ask  strategic  questions  and  help  steer  them.) 

4.  Product  concept  formulation  -  (Prior  to  committing  resources). 

5.  Stabilizing  the  product  definition.  -  (Defining  what  you  want  to  build.)™ 

6.  Early  consideration  of  supply  chain  factors.  -  (Before  you  even  build  the  project.) 

7.  Sophisticated  project  planning.  -  (If  it’s  not  sensitive  to  technology  issues,  you  introduce  all  sorts  of 
risk.  There  are  lots  of  contingency  planning,  understanding  of  variances  in  costs,  schedules,  etc” 
(Rosenthal  1998,  pg.  11). 

Cycle  Time  in  the  Front  End 

Patterson  introduces  the  concept  of  the  Innovation  Life  Cycle.  The  time  is  the  ‘time  the 
opportunity  for  a  new  product  occurs.’  “It  is  a  philosophical  point  in  time,  not  usually  discernible:  the 
moment  when  emerging  technology  overlays  a  customer  need  and  triggers  a  new  product  possibility. 
This  definition  is,  of  course,  variable  with  circumstance”  (Patterson  1993). 

“Product  innovation  cycle  time  is  the  time  between  the  moment  when  the  window  opens  and  the 
moment  the  first  customers  are  satisfied.  The  opportunity  occurs  and  generally  is  followed  by  some 
delay  until  time  ‘Tp’  when  it  is  perceived.  It  is  business’  job  to  reduce  that  delay  time  to  a  minimum 
and  get  a  product  into  that  window  as  quickfy"  as  possible”  (Patterson  1993). 

“The  objea  of  product  development  then  is  to  identify  opportunities,  define  the  most  competitive 
produa  possible  and  get  the  produa  to  market  expeditiously.  Once  the  produa  definition  is  frozen, 
the  primaiy  faaor  that  determines  return  on  investment  is  the  speed  with  which  that  produa  comes  to 
life”  (Patterson  1993).  Requirements  stability  is  very  important.  The  basic  idea  is  that  if  you  can  get 
things  out  the  door  sooner,  the  less  likely  you  will  need  to  change  requirements.  Waste  coming  from 
mid-stream  changes  will  be  much  less  if  praaiced  (Patterson  1993). 


50  For  competencies  4  and  5,  the  issue  is  defining  them,  putting  them  into  a  process,  and  have  people  foflowing  it.  Also,  poor 
specification  is  the  #  1  cause  of  delay  (unanticipated  R&D  spending). 
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“Reducing  dead  time  is  best  achieved  through  effective  strategic  planning,  market  research,  and 
technology  research.  Every  business  should  -  must,  if  it  expects  to  be  successful  -  maintain  an  on¬ 
going  program  which  scans  technological  innovations,  tracks  competitors’  aaivities,  and  actively 
pursues  the  perception  of  customer  needs  and  expeaations.  This  program  should  be  operating  in  the 
background  at  all  times  and  should  be  constantly  comparing  market  needs  with  emerging  technologies 
to  perceive  opportunities  that  are  relevant  to  the  business.  This  ongoing  program  is  a  relatively  low- 
cost  effort,  probably  the  most  cost-effective  approach  available  for  reducing  the  elapsed  time  between 
the  time  the  opportunity  occurs  T^’  and  the  time  the  first  customers  are  satisfied  ‘T/”  (Patterson 
1993). 

Stages  of  Searching  for  User  Needs /Requirements 

Conway  and  McGuiness  conduaed  a  study  of  nine  firms  that  indicated  that  the  development  of  new 
product  ideas  consists  of  three  stages:  the  detection  stage,  the  credibility-seeking  stage,  and  the 
intensive  search  stage.  “As  a  concept  advanced  through  the  process,  it  not  only  became  more  defined, 
but  also,  moved  to  becoming  more  and  more  of  an  organizational,  rather  than  individual,  priority.  If 
accepted  by  the  formal  project  development  system,  the  developed  concept  becomes  a  formally 
funded  organizational  priority”  (Conway  and  McGuinness  1986,  pg.  285).  Usually  the  detection  stage 
consists  of  ideas  shared  by  a  few  people  or  just  an  individual.  These  people  understand  the  risks  of  the 
idea  as  well  as  how  the  idea  is  consistent  with  the  strategic  goals  of  the  company  (Conway  and 
McGuinness  1986).  Credibility-seeking  simply  means  keeping  the  idea  alive  and  broaden  the  circle  of 
support;  to  some  it  means  ‘overcoming  resistance’  (Conway  and  McGuinness  1986).  The  Intensive 
Search  stage  is  a  formal  technical  and  market  analysis  into  the  feasibility  of  the  idea  where  company 
resources  are  expended  to  further  develop  the  idea  (Conway  and  McGuinness  1986).  This  stage 
gathers  the  information  needed  for  the  business  case  of  the  project. 

Theoretical  Framework  to  generate  requirements  from  information 

Cooper  and  Wootton  developed  a  framework  after  studying  the  telecommunications,  automotive  and 
IT^^  industries.  They  indicate  that  generation  of  requirements  has  three  parts:  gathering  of  the 
information;  transforming  it;  and  generating  the  requirements  (Cooper,  Wooten  et  al.  1998).  The  main 
contribution  of  their  work  recognizes  that  “the  derivation  of  any  information  that  a  source  can  give  is 
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the  interaction  of  two  separate  factors:  their  internal  cognitive  influences  (i.e.  their  preferences,  beliefs, 
values  and  emotions);  and  their  external  received  influences  (i.e.  their  physical  senses,  education, 
received  knowledge,  experience)”  (Cooper,  Wooten  et  al.  1998,  pg.  505).  They  further  indicate  that 
the  environment  that  this  information  is  received  (hostile,  friendly,  relaxed,  formal,  etc.),  impacts  the 
outcome  of  these  stages  (Cooper,  Wooten  et  al.  1998).  When  multiple  individuals  are  involved  in  the 
generation  of  requirements,  there  is  also  the  potential  for  misunderstanding.  For  instance,  there  can 
be  Shared  Understanding  (a  common  interpretation  of  the  data),  or  Agreed  Shared  Understanding  (not 
necessarily  a  common  interpretation  of  the  data)  (Cooper,  Wooten  et  al.  1998).  As  the  information  is 
gathered,  there  is  a  ‘transformation  event’  that  occurs  with  each  individual  that  then  must  be  resolved 
through  interaction,  discussion  and/or  argument  (Cooper,  Wooten  et  al.  1998).  This  sequence  of 
events  also  occurs  during  the  generation  of  each  requirement. 
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Appendix  B  -  Techniques  to  gather  user  needs  and  requirements 

The  next  paragraphs  illustrate  the  current  methods  employed  by  firms  to  gather  user  needs  and 
requirements.  These  are  not  all  used  everywhere,  but  most  commercial  firms  employ  several  forms  to 
accomplish  these  tasks.  Additionally,  the  Center  for  Innovation  in  Product  Development  (CIPD)“  at 
the  Massachusetts  Institute  of  Technology  has  many  research  projects  underway  to  expand  the  body 
of  knowledge  available  to  the  practitioner  about  New  Product  Development.  Highlights  of  some  of 
their  research  efforts  will  be  presented  in  the  following  sections. 

Sources  of  ideas 

The  popular  press  has  talked  a  lot  about  technology-push  and  customer-pull  as  being  the  sources  for 
many  new  product  development  projects.  Technology-push  refers  to  the  activity  of  an  organization 
forcing  technology  into  the  product  or  an  organization  that  actively  markets  technology  for  inclusion 
into  a  product.  Customer-puU  favors  relying  upon  the  customer  to  dictate  the  timing  of  new  products 
(i.e.  when  and  what).  As  these  are  somewhat  ubiquitous  no  further  discussion  of  these  terms  will  be 
given.  Conway  and  McGuinness  add  to  these  two  types  of  sources  four  others.  These  categories  are 
called:  Market-Driven,  Close-Follower,  Planned-Diversification,  and  Opportunistic-Diversification. 
Market-Driven  describes  when  problems  or  opportunities  are  discovered  from  serving  a  specific 
market  and  also  understanding  the  needs  of  that  market.  Close-Follower  describes  problems  or 
opportunities  discovered  by  matching  new  products  that  are  developed  by  a  competitor.  Planned- 
Diversification  describes  entering  a  new  market  specifically  and  strategically  to  diversify  from 
traditional  markets  and/ or  products.  Opportunistic-Diversification  describes  entering  a  new  market, 
although  the  company  had  no  intention  of  originally  doing  so.  Of  these  processes,  %  of  the  processes 
used  by  the  companies  in  their  study  were  market-driven  or  customer-pull  (Conway  and  McGuinness 
1986). 

To  bring  greater  understanding  to  the  variety  of  techniques  that  are  used  to  gather  data,  chararterize  it, 
prioritize  it,  optimize  it,  and  finally  test  it,  Dahan  identifies  several  categories.  Although  his  notional 
categories  will  be  used  in  the  discussion  below,  he  acknowledges  they  are  not  all-inclusive  (Dahan 
1998). 

52  CIPD  maintains  a  World-Wide-Web  home  page.  For  more  information,  visit  http://web.mit.edu/ cipd/ 
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Subject  Matter  Experts  (SME) 

This  method  consists  of  a  knowledgeable  expert  in  a  given  field.  This  person  may  be  a  current  or  past 
operator  or  customer  of  the  firm  or  its  products.  The  SME  acts  as  a  conduit  of  information  for  a 
developer  of  a  produa,  process,  or  service,  with  which  the  SME  has  extensive  experience.  A  good 
SME  is  able  to  articulate  the  knowledge  he  or  she  possesses  in  a  manner  that  is  not  necessarily  steeped 
in  the  language  of  the  domain  in  question.  In  theory,  this  is  not  very  difficult.  In  practice,  this  is  one 
of  the  most  difficult  areas  to  master. 

Lead  Users 

This  is  a  form  of  innovation  and  discovery  of  user  needs  that  the  user  does  on  its  own.  Lead  Users  are 
product  users  that  have  the  motivation,  drive,  and  technical  know-how  to  improve  upon  or  modify  an 
existing  product,  process,  or  service  to  meet  their  needs  and  reap  significant  benefits  (vonHippel 
1988).  Furthermore,  Lead  Users  face  these  needs  much  earlier  than  the  general  marketplace  will, 
usually  on  the  order  of  months  or  years  (vonHippel  1988).  Therefore,  identification  of  these  Lead 
Users  is  essential  in  order  to  identify  needs  and  have  enough  time  to  be  able  to  produce  a  product, 
process,  or  service  that  coincides  with  the  general  marketplace’s  identification  of  a  need  (vonHippel 
1988).  An  important  point  to  remember  is  that  Lead  Users  are  not  necessarily  ‘Early  Adopters’ 
(vonHippel  1988). 

QFD 

Quality  Funaion  Deployment  can  be  used  for  many  purposes.  In  the  case  of  user  needs,  QFD  is  a 
useful  tool.  QFD  is  a  method  to  take  user  needs  and  translate  them  into  product,  process,  or  service 
attributes.  It  uses  a  matrix  form  to  relate  the  needs  to  attributes.  The  method  also  allows  for 
conflicting  attributes  to  be  quickly  identified  for  resolution.  "The  house  of  quality  is  a  kind  of 
conceptual  map  that  provides  the  means  for  interfunctional  planning  and  communications.  People 
with  different  problems  and  responsibilities  can  thrash  out  design  priorities  while  referring  to  patterns 
of  evidence  on  the  house's  grid"  (Hauser  and  Clausing  1988).  "The  driving  force  behind  QFD  analysis 
is  a  short,  accurate  list  of  key  customer  needs.  These  needs  are  related  to  produa  attributes  that  are 
then  evaluated  as  to  how  well  they  meet  the  needs.  Produa  attributes  are  also  "benchmarked"  against 
competitors'  features  weighted  by  their  ability  to  meet  customer  needs  better  than  those  of 
competitors"  (Dahan  1998,  pg.  13).  A  study  by  "Jerry  Wind  and  Vijay  Mahajan  that  surveyed  firms 
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about  the  needs-finding  techniques  they  used  when  developing  new  products  found  that  ...  less  than 
one  in  ten  used  Quality  Function  Deployment"  (Dahan  1998,  pg.  7). 

Conjoint  Analysis 

Conjoint  Analysis  is  a  technique  for  prioritizmg  customer  needs  and  preferences.  It  is  extremely  useful 
when  the  product,  process,  or  service  in  question  is  selected  based  upon  multiple  attributes  and  the 
trade-offs  customers  make  between  them  (Dahan  1998).  These  attributes  are  tied  direaly  to  customer 
needs  (Dahan  1998).  Additional  variations  to  this  method  employ  the  use  of  orthogonal  arrays  or  an 
experimental  approach  known  as  Taguchi  methods  (Dahan  1998). 

Pugh  Method 

The  method  proposed  by  Pugh  is  one  of  concept  selection.  It  is  designed  to  identify  those  concepts 
with  the  best  and  strongest  concepts.  This  method  goes  further  by  allowing  specific  product  attributes 
to  be  identified  according  to  strengths  and  weaknesses.  This  allows  potentially  new  concepts  to  be 
conceived  based  upon  the  strengths  of  several  competing  others  (Pugh  1996).  The  method  works  by 
first  taking  a  well-established  produa  as  the  Datum^^.  Competing  new  produas  are  then  scored 
against  the  attributes  of  this  product  with  a  simple  plus  or  minus  sign  per  attribute.  These  are  then 
added  and  each  new  concept  has  a  relative  idea  of  how  it  compares  to  each  of  the  other  new  designs 
and  the  Datum.  "It  pools  the  best  properties  of  the  several  competing  approaches  to  create  a  brand- 
new  and  even  better  approach"  (ZangwHl  1993). 

Kano  Analysis 

Another  method  by  which  one  can  charaaerize  customer  needs  according  to  their  expectations  is 
called  a  Kano  Analysis.  There  are  three  levels  of  needs  in  the  Kano  model  (Dahan  1998).  First,  a  User 
Need  can  be  characterized  as  a  'must  have',  where  its  absence  will  prevent  the  user  from  even 
considering  the  product,  process,  or  service.  Second,  there  are  needs  characterized  by  'more  the 
better'.  Here,  the  need  leads  to  greater  user  satisfaction  the  more  the  level  of  the  attribute  is  present. 
Lastly,  there  are  needs  characterized  as  'delighters';  needs  that  users  don't  actually  expect  to  be  fulfilled 
or  are  aware  of.  Delivery  of  these  attributes  becomes  strong  motivators  for  purchase  and  satisfaction. 


53  The  reference  point  or  data  baseline. 
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Repertory  Grids  and  Perceptual  Maps 

Additional  ways  to  categorize  user  needs  that  have  been  gathered  by  various  methods  are  using 
Repertory  Grids  and  Perceptual  Maps.  They  serve  to  identify  common  themes  and  patterns  that  exist 
in  multiple  user  responses.  K-J  analysis  is  one  example  of  this  use  (Dahan  1998).  K-J  analysis  is  a 
structured  method  to  gather  and  analyze  qualitative  data  when  users  can  identify  a  product  concept, 
but  are  unclear  on  the  concepts  important  dimensions  {Leonard-Barton,  Wilson  et  al.  1994). 

Empathic  Design 

Leonard  and  Rayport  articulate  the  notion  that  sometimes  users  are  not  aware  of  their  own  needs 
(Leonard  and  Rayport  1997).  "What  customers  can't  teU  you  might  be  just  what  you  need  to  develop 
successful  new  products"  (Leonard  and  Rayport  1997,  pg.  102).  Either  they  have  become  accustomed 
to  working  with  existing  products  or  they  don't  realize  that  there  could  be  an  entirely  different  way  of 
doing  things  or  both  (Leonard  and  Rayport  1997).  The  basis  for  Empathic  Design  rests  upon 
observation  of  the  customer  in  their  natural  environments.  Five  pieces  of  important  information  can 
be  found  through  observation.  They  are  triggers  of  use,  interactions  with  the  user's  environment,  user 
customization,  intangible  attributes  of  the  product  and  unarticulated  user  needs  (Leonard  and  Rayport 
1997).  Further  the  process  usually  encompasses  five  steps;  observation;  capturing  data;  reflection  and 
analysis;  brainstorming  for  solutions;  and  developing  prototypes  of  possible  solutions  (Leonard  and 
Rayport  1997). 

Focus  Groups 

This  method  of  eliciting  user  needs  takes  methods  of  interviewing  and  surveys  and  places  it  in  a  group 
setting.  Flere,  it  is  hoped  that  the  interaaion  among  the  different  members  of  the  focus  group  (its 
composition  itself  is  worthy  of  study),  will  elicit  ideas  and  needs  in  a  manner  that  is  much  quicker  than 
individual  data  gathering  might  uncover.  Of  course,  some  of  the  concerns  deal  with  'group  think'  that 
would  eliminate  useful  ideas  prematurely. 

Interview  and  Surveys 

These  can  be  very  effertive  in  determining  user  needs,  particularly  for  evolutionary  designs  targeted  at 
an  existing  or  familiar  customer  base  (Dahan  1998).  Griffen  and  Hauser  have  determined  that  "ten  to 
twenty  interviews  per  market  segment  elicit  the  vast  majority  of  customer  needs"  (Dahan  1998).  The 
challenges  posed  by  this  method  is  that  it  can  be  very  time  intensive,  there  needs  to  be  an  incentive  for 
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the  user  to  participate,  and  constructing  the  interview  or  survey  questions  can  be  very  difficult.  It  is 
important  to  not  introduce  any  bias  into  these  questions  (Dahan  1998).  Also,  capturing  the  actual 
'voice  of  the  customer'  is  critical  as  opposed  to  what  the  interviewer  thought  the  interviewee  said 
(Dahan  1998). 

Cultural  Anthropology 

This  is  another  term  for  design  ethnography.  It  is  closely  related  to  empathic  design.  "Cultural 
anthropology  is  the  study  of  hidden  meanings  underlying  products,  or  meanings  which  are  sought,  but 
left  unmet.  The  approach  is  broader  than  psychology-based  motivational  research  in  that  it  accounts 
for  customers'  social  values,  not  just  emotional  needs"  (Dahan  1998).  Those  that  work  in  this  field  are 
social  scientists,  anthropologists  and  psychologists.  They  bring  a  disciplined  approach  to  the  field  of 
new  product  development  and  help  companies  determine  how  people  use  their  products  (Takahashi 
1998).  It  allows  them  to  study  relatively  few  subjects  and  focus  on  'big  insights'  rather  than  statistical 
data  (Takahashi  1998). 

Toolkits 

These  are  ways  to  facilitate  user  innovation  and  decrease  the  time  required  to  move  from  requirements 
to  produaion.  Von  Hippel,  who  also  first  identified  the  phenomenon  of  Lead  Users,  first  noted  the 
praaice  of  using  toolkits  (vonHippel  1999).  It  was  first  used  in  the  semi-conductor  industry  and  has 
since  spread  elsewhere,  such  as  the  food  service  industry  and  also  to  commercial  helicopter  design 
(V anBuiten  1999;  vonHippel  1999).  For  instance,  master  chefs  are  able  to  use  toolkits  to  create  food 
products  and/ or  recipes  that  can  be  easily  duplicated  regardless  of  the  abilities  of  the  person  preparing 
the  food.  This  has  far-reaching  implications,  particular^  for  chain  restaurants,  that  want  to  ensure  a 
similar  and  consistent  customer  experience  regardless  to  which  chain  restaurant  the  customer 
frequents. 
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Appendix  C  -  Tools  and  Technology  Enablers  for  the  Front  End  of  Product 
Development 

There  are  several  enablers  that  are  designed  to  facilitate  good  front-end  processes.  One  such  enabler  is 
the  tool  used  in  requirements  generation.  Tools  for  requirements  are  varied.  However,  the  common 
feature  for  all  of  the  tools  is  that  requirements  are  traced  from  conception  or  its  source  to  its  latest 
incarnation.  According  to  Birkler,  each  of  them  has  features  and  applicability  that  can  be  highly 
dependent  on  a  company’s  overall  processes  and  information  technology  philosophies  (Birkler  1999). 
Each  tool  has  its  own  strengths  and  weaknesses  and  requires  a  long-term  commitment  by  a  company 
for  it  to  obtain  the  benefits  of  the  investment  (Birkler  1999).  The  following  section  gives  an  overview 
of  some  of  the  tools  available.  It  is  not  intended  to  be  all-inclusive  list,  or  an  analysis  of  the  affectivity 
of  these  tools  compared  to  each  other. 

IRSS 

IRSS  is  a  Booz-AUen  &  Hamilton  developed  tool  designed  specifically  for  the  US  Air  Force’s 
Requirements  Process.  IRSS  stands  for  the  Integrated  Requirements  Support  System.  It  uses  client- 
server  architecture  and  can  become  an  organization’s  information  architecture  -  moving  beyond 
requirements  (Booz-Allen  &  Hamilton  1999).  The  system  is  organized  around  ‘projects’  which  are  the 
subjects  of  the  Requirements  documentation  (Booz-Allen  &  Hamilton  1999).  It  also  will  correlate 
resources  with  tasks  required  for  the  project;  it  is  a  suspense-tracking  tool  (Booz-Allen  &  Hamilton 
1999).  All  users  of  IRSS  are  able  to  connect  with  each  other  virtually  and  participate  in  the 
development  of  a  project’s  requirements  (Booz-Allen  &  Hamilton  1999).  Lastly,  IRSS  facilitates  the 
documented  portion  of  a  projea’s  requirements.  AH  documents  created  in  IRSS  are  fully  text 
searchable  and  accessible  no  matter  the  physical  location  of  the  document  (Booz-Allen  &  Hamilton 
1999).  The  US  Air  Force  is  scheduled  to  have  this  tool  deployed  to  all  of  its  locations  by  the  end  of 
2000.  Currently,  the  Army  is  using  this  tool  and  has  given  favorable  feedback. 

Caliber-RM 

This  has  an  object-oriented  database  that  “hierarchically  organizes  requirements,  with  those 
requirements  organized  into  projects  that  make  up  one  or  more  sets  or  types  of  requirements”  (Feibus 
1998,  pg.  1).  It  features  requirements  traceability  and  security,  as  well  as  interfaces  to  popular  word 
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processing  and  database  software  programs  (Feibus  1998).  It  also  has  add-on  tools  that  will  connect  it 
with  the  Internet  (Feibus  1998).  It  is  in  use  by  many  aerospace  companies. 

IcCONCEPT  RTM 

IcCONCEPT  RTM  has  a  client/server  architecture  that  “allows  companies  to  automate  the 
information-gathering  and  engineering  processes,  making  it  easier  to  capture  and  understand  customer 
demands  and  concerns.  The  tool  organizes  this  information,  ensuring  that  product  requirements  are 
met  in  all  phases  of  the  development  cycle  -  from  product  concept  through  product  deHveiy”  (Birkler 
1999).  Filling  out  computer-based  forms  captures  information.  End  users,  product  development 
personnel,  or  anyone  else  the  company  has  allowed  access  can  do  this.  It  is  also  in  use  by  many 
aerospace  companies. 

DOORS 

The  acronym  DOORS  stands  for  Dynamic  Object-Oriented  Requirements  System.  This  is  another 
requirements  management  tool.  It  is  able  to  be  tailored  to  the  customer’s  desires  and  has  version 
control  features,  import  and  export  links  using  standard  interfaces  into  most  software  applications,  and 
flexible  reporting  features  (Feibus  1998).  It  also  can  be  used  on  other  operating  systems  like  Unix 
(Feibus  1998).  One  add-on  available  allows  the  DOORS  functionality  to  work  through  the  Internet 
(Feibus  1998).  “In  Doors,  requirements  are  called  objects,  which  are  grouped  into  modules,  which  are 
part  of  a  project.  Objeas  have  attributes,  which  {can  be  tailored}  to  the  needs  of  a  specific  module  ... 
Module  and  requirement  change  history  are  maintained  for  auditing  purposes,  and  ...  baseline  versions 
of  entire  modules  for  tracking  module  revisions”  can  be  created  (Feibus  1998).  The  system  can  be 
accessed  through  a  network  and  maintain  thousands  of  links  and  objects  (Birkler  1999).  It  also  will 
ensure  compliance  with  the  ISO  13485  quality  control  standard  (Birkler  1999). 

Executive  Management  Information  Systems 

These  are  tools  used  by  upper  management  and  executives  to  keep  pulse  on  their  organizations.  There 
are  several  of  these  available  commercially  and  will  not  be  reviewed  here.  They  are  tools  such  as 
ERP^'^,  SAP,  etc.  One  such  tool  is  Expert  Choice.  This  tool  is  based  upon  the  use  of  two  processes. 
These  are  the  Analytic  Flierarchy  Process  (AHP)  and  the  Analytic  Network  Process  (ANP)  (Expert 
Choice  1999).  AHP  is  a  methodology  developed  over  20  years  ago  and  is  used  for  complex,  multi- 
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criteria  problems  where  both  qualitative  and  quantitative  issues  must  be  addressed  (Expert  Choice 
1999).  ANP  is  an  extension  of  the  AHP  methodology.  It  incorporates  feedback  among  the  different 
problem  elements  as  well  as  any  dependencies  that  exist  between  them  (Expert  Choice  1999). 

DOME 

DOME  is  a  tool  developed  by  MIT’s  CIPD  that  strives  to  reduce  the  time  to  design  new  products. 
DOME  stands  for  Distributed  Objea-based  Modeling  Environment.  “Dome  provides  the 
framework  that  permits  the  experts  involved  in  designing  a  new  product  to  use  the  various  software 
tools,  models  and  data  most  appropriate  for  each  area  of  expertise,  yet  still  allows  rapid  exploration  of 
the  tradeoffs  of  different  design  attributes”  (Wallace  and  Wang  1999,  pg.  1).  The  biggest  contributions 
this  tool  makes  to  New  Product  Development  comes  through  creating  a  common  interface  to  already 
existing  software  tools  used  ranging  from  word  processing  files,  to  spreadsheets,  to  detailed  drawing 
packages.  It  also  facilitates  the  abiKty  to  quickly  assess  alternatives  (Wallace  and  Wang  1999). 
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Appendix  D  -  Observations  about  the  PPBS  and  the  US  Air  Force 

The  combined  outputs  of  each  individual  MAJCOM’s  Planning  Process  produce  a  fiscally 
unconstrained  list  of  needs.  In  the  aggregate,  the  sum  total  of  these  outputs  would  increase  the  AF 
budget  beyond  what  the  budget  can  sustain.  This  problem  persists  even  when  assuming  a  10%  growth 
in  the  current  funding  levels.  For  example,  according  to  one  source  within  the  Air  Force  Acquisition 
Office,  in  any  given  year,  a  particular  item  can  be  the  number  one  requirement  for  a  MAJCOM. 
Efforts  are  made  to  secure  funding,  and  once  this  occurs,  it  drops  on  the  priority  list.  Perhaps  this  is 
due  to  rotating  leadership,  or  aaion  officers  ‘trying  to  push  their  program  through’  so  they  can  get  a 
good  performance  evaluation,  or  other  reasons,  or  simply  acknowledgement  that  this  is  the  only  way 
for  programs  to  get  the  funding  they  need.  When  things  drop  in  priority,  this  introduces  ‘turbulence’ 
and  more  chaos  into  an  already  turbulent  system.  Often,  the  reaction  of  the  system  is  to  delay,  modify, 
and/ or  change  the  program  in  question  to  remain  viable.  Furthermore,  it  is  well  known  that  once 
funding  is  secured,  it  is  very  difficult  to  turn  off  that  funding  (Hill,  Jr.  et  al.  1986). 

Additionally,  no  one  really  knows  how  effeaive  the  Modernization  Planning  Process  (MPP)  is. 
Interviews  with  15  participants  in  the  process  indicate  a  general  consensus  that  the  system  is  “broken” 
or  “too  slow”.  However,  there  is  little  quantifiable  data  to  validate  this  perception.  Air  Force  Policy 
Document  (AFPD)  10-14,  Modernization  Planning,  released  in  1995,  mandates  the  use  of  the 
‘Strategy-to-task’  philosophy  and  also  mandates  the  use  of  a  metric  to  evaluate  the  effectiveness  of  the 
MPP  (USAF  1996).  This  metric  is  defined  as  the  number  of  MPP  produas  that  are  placed  into  the 
PPBS.  Contact  with  AF  officials  in  the  Pentagon  Strategic  Planning  Directorate  indicates  that  this 
information  is  not  being  colleaed  by  the  Air  Force  and  that  the  Air  Force  policy  document  is  in  the 
process  of  being  rewritten  to  remove  the  measurement  requirement. 

The  produas  of  the  MPP  process  emerge  after  11/2  years  to  2  years  within  the  system.  This  does  not 
include  the  delays  then  encountered  by  the  Requirements  Generation  System  and  also  the  PPBS.  AH 
of  these  processes  are  serial  in  nature,  although  efforts  are  made  to  run  these  systems  in  parallel  as 
much  as  possible.  The  time  period  mentioned  earlier  is  now  the  usual  norm.  7\ji  additional  1  to  2 
years  is  usually  required  to  get  through  the  other  systems. 
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The  second  step  of  the  PPBS,  Programming,  begins  as  the  MAJCOM  individually  rank-orders  the 
potential  solutions  listed  in  the  MAP,  in  order  of  preference,  in  its  Programming  (POM)  and  FYDP 
inputs.  It  should  use  the  MAP  to  develop  the  POM  for  the  MAJCOM.  Any  programmed  item  that  is 
new  must  be  documented  in  a  Mission  Area  Plan  as  per  AF  Instruction  10-1401  (See  also  USAF 
1996).  The  AF  then  shapes  an  overall  plan  from  all  of  the  MAJCOM  inputs  and  determines  which 
projects  to  place  in  the  AF  POM  and  FYDP.  This  is  done  as  the  Air  Force  builds  its  PPBS 
documents  (POM,  BES,  etc.)  through  a  series  of  reviews.  Hard  decisions  must  be  made  at  every  step 
to  determine  where  the  scarce  resources  should  be  allocated  among  the  different  requests.  The 
MAJCOM  inputs  are  passed  by  various  Program  Element  Monitors^^  (PEMs)  to  one  of  14  Panels  that 
are  organized  according  to  Air  Force  mission  and  core  competencies.  Integrated  Process  Teams  (IPT) 
that  seek  to  balance  programs  within  the  panel’s  area  support  the  Panels. 

Composition  of  AF  Panels 


Panel:  Primary  entry  pointto  AFCS  for  MAJCOM  Info 

Figure  77.  Composition  of  the  Air  Force  Panel  (Plummer  1999) 

55  These  individuals  concern  themselves  with  the  fiscal  accountability  of  moneys  used  by  weapon  systems  in  partiailar  mission  areas. 
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Upon  completion  of  their  work,  the  next  review  committee  is  called  the  Air  Force  Group.  They 
analyze  and  resolve  decisions  made  by  the  different  panels.  This  is  the  first  time  there  is  a  corporate 
look  at  the  entire  integrated  Air  Force  proposed  program.  The  next  step  is  done  by  the  Air  Force 
Board  that  resolve  other  issues  not  done  by  the  Group.  The  last  step  in  the  process  is  a  review  by  the 
Air  Force  Gouncil.  The  members  of  this  council  are  the  staff  members  of  the  Air  Force  Chief  of  Staff 
and  the  Secretary  of  the  Air  Force.  The  final  approval  comes  from  the  Chief  of  Staff  and  the  Secretary 
of  the  Air  Force  (Plummer  1999).  The  people  making  these  decisions  are  not  a  part  of  the 
Requirements  Generation  System;  nevertheless,  they  end  up  making  decisions  and  trading-off 
requirements  in  their  effort  to  put  together  a  balanced,  fiscally  constrained  financial  plan. 

Air  Force  Corporate  Structure 


Figure  78. 


Air  Force  Corporate  Structure  (Plummer  1999) 
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Appendix  E  -  Generic  (Non-Service  Specific)  Requirement  Document 
Generation  Process 


Figure  79.  Generic  (Non-Service  Specific)  Mission  Need  Statement 

Generation  Process 
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Figure  80.  Generic  (Non-Service  Specific)  CRD  Generation  Process 
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Figure  81.  Generic  (Non-Service  Specific)  ORD  Generation  Process 
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Appendix  F  -  Details  about  the  Acquisition  System  in  the  Air  Force 

The  Acquisition  System  of  the  Air  Force  does  not  differ  substantially  from  the  general  process 
outlined  in  the  section  in  Chapter  2.  The  activities  of  the  acquisition  system  for  the  7\ir  Force  in  the 
pre-milestone  zero  phase  are  limited  to  the  interactions  of  Technical  Planning  Integrated  Product 
Teams  with  those  conducting  Mission  Need  Analysis  studies  and  Mission  Solution  Analysis  studies. 
The  TPIPTs  interact  with  them  as  well  as  the  labs  and  other  sources  of  new  technology.  They  often 
participate  in  the  technical  evaluation  of  new  concept  ideas  and  potential  solutions  during  this  time. 
Additionally,  cost  analysts  help  evaluate  projected  program  costs  and  support  the  TPIPTs. 

Participation  of  Acquisition  personnel  in  Phase  Zero  is  usually  limited.  The  Organization  of 
Aerospace  Studies  (OAS)  is  an  organization  that  develops  and  promotes  ‘Best  Practices’  in  conducting 
Analysis  of  Alternatives.  They  do  not  mn  these  analyses  (the  MAJCOMs  do),  but  they  serve  as 
consultants  to  the  process. 

Should  an  existing  weapon  system  be  the  source  of  a  new  requirement,  the  process  requires  it  to  go 
through  the  full-blown  weapon  system  development  process  of  drafting,  validating,  and  approving  a 
Mission  Need  Statement  and  an  Operational  Requirements  Document.  Therefore,  in  this  case,  the 
System  Program  Office  will  be  aaive  during  the  first  two  phases,  simply  because  of  the  relationship  it 
has  with  the  new  system.  Nevertheless,  the  SPO  will  be  active  only  in  a  secondary  role  -  the  user  is 
still  responsible  until  reaching  Milestone  I  decision  (although  the  user  may  ask  the  SPO  to  run  the 
AoA  on  their  behalf). 

Finally,  Air  Force  laboratories  are  considered  part  of  the  Acquisition  System  and  participate  in  the 
process  by  furthering  research  iato  those  areas  identified  by  the  warfighter,  in  conjunction  with  the 
TPIPTs  that  demand  further  development. 
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Appendix  G  -  Proposed  improvements  to  the  current  Air  Force  system 

Now  that  the  current  system  has  been  explained  and  put  into  perspective,  there  are  efforts  underway 
to  change  the  system  -  partly  as  a  result  of  the  previously  identified  problems  and  also  in  a  desire  to 
improve  the  system.  Interestingly,  the  vast  majority  of  these  efforts  are  in  the  realm  of  strategic 
planning  -  where  user  needs  are  initially  identified.  If  the  best  place  to  influence  the  outcome  of  a 
system  is  at  the  front-end,  then  this  is  the  most  logical  place  to  begin  reforms. 

One  study  framed  the  issues  with  the  following  introduction.  “Ideally,  broad  thinking  about  how 
specific  missions  might  be  accomplished  should  precede  decisions  about  what  kinds  of  platforms, 
what  classes  of  technologies,  or  which  military  service  is  most  appropriate  for  particular  tasks.  Too 
often,  however,  these  steps  in  the  process  of  planning  force  modernization  are  reversed.  As  a  result, 
concept  development  sometimes  becomes  more  an  exercise  in  finding  a  use  for  a  given  technology, 
platform,  or  operational  method  rather  than  in  finding  the  right  technology  or  platform  to  perform  a 
specific  funaion.  Thinking  about  alternative  options  is  narrowed,  and  competition  among  alternative 
concepts  Is  weakened”  (Birkler  1998,  pg.  xi). 

“Given  this  context,  as  one  thinks  about  approaches  to  force  planning  methods,  three  principles 
should  be  kept  in  mind; 

•  Traditional  “threat-based  planning,”  the  stalwart  of  defense  planning  for  decades,  is  no  longer  an 
adequate  basis  for  mid-  and  long-range  planning  (see,  e.g..  Secretary  of  Defense  William  J.  Perry’s 
1996  report  to  Congress).  Focusing  on  a  few  point  scenarios  suppresses  too  many  issues 

•  National  security  planning  should  instead  confront  head-on  the  reality  of  substantial  uncertainty  in 
many  dimensions,  political  and  strategic  as  well  as  purely  military 

•  Planning  activities  should  be  forward  looking:  They  should  focus  on  the  long  term,  and  they 
should  encourage  examination  of  options  for  changing  strategy,  forces,  and  doctrine”  (Davis  1996, 
pg.  xi). 

The  following  excerpts  from  papers,  reports,  and  articles  summarize  some  of  the  existing  proposals  to 
change  the  way  strategic  planning  is  done  within  the  military.  They  aU  have  very  relevant  points  and 
address  real  issues  seen  as  drawbacks  in  the  current  system. 

One  paper  suggests  a  total  reorganization  of  the  Office  of  the  Under  Secretary  of  Defense  for 
Acquisition  and  Technology.  The  reason  is:  “the  office  has  not  changed  in  the  face  of  several  DoD 
initiatives  in  such  areas  as  greater  use  of  commercial  technology,  lean  production,  outsourcing,  and 
joint  warfare"  (Bracken,  Birkler  et  al.  1996,  pg.  v). 
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The  principle  argument  is  that  stracture  should  match  strategy.  One  option  that  is  particularly 
aggressive  is  for  the  creation  of  a  stmcture  with  the  following  parts: 

•  "A  science  and  technology  office  with  a  broader  charter  than  the  current  one. 

•  A  concept  development  and  joint  integration  office  with  a  charter  to  formulate,  evaluate,  and 
define  concepts  in  each  mission  area.  This  office  would  be  organized  around  two  themes; 
operational  concepts  and  system  concepts  and  their  demonstration. 

•  An  acquisition  office,  which  would  oversee  platforms  and  systems.  This  office  would  be 
organized  according  to  type  of  platform”  (Bracken,  Birkler  et  al.  1996,  pg.  v  -  vi). 

StiU  another  study  recommends  major  changes  that  would  de-emphasize  the  “deliberate  planning 
system,”  elevate  the  importance  of  “crisis-action  planning,”  and  use  frequent,  rigorous  exercises  to  test 
and  refine  the  ability  to  develop  and  execute  in  the  development  and  creation  of  appropriate  plans  in 
crisis  (Davis  1993).  “The  approach  would  depend  on  building-block  methods  that  are  quite 
comfortable  to  many  American  military  officers,  and  which,  indeed,  can  already  be  seen  at  work  at 
lower  levels  of  organization.  ...  The  study  also  recommends  that  strategic  and  programmatic  planning 
be  changed  in  ways  that  would  be  more  consistent  with  planning  under  uncertainty  and  encouraging 
flexibility  and  adaptiveness  rather  than  optimization  for  well-defined  scenarios”  (Davis  1993, 
Abstract). 

Another  strategic  planning  methodology  RAND  has  developed  over  the  last  four  years  is  called 
Assumption-Based  Planning  (ABP).  The  five  steps  of  the  methodology  are  (1)  identifying  important 
assumptions  underlying  an  organization’s  operations  or  plans;  (2)  identifying  assumption  vulnerabilities 
within  the  planning  horizon;  (3)  defining  signposts  (i.e.,  indicators  or  warning  signs  of  a  change  in  an 
assumption’s  vulnerability);  (4)  defining  shaping  actions  (actions  taken  to  avert  or  cause  the  failure  of 
an  assumption);  and  (5)  defining  hedging  actions  (actions  taken  to  better  prepare  for  the  failure  of  an 
assumption)  (Dewar  1993).  The  report  compares  ABP  with  other  methodologies.  It  argues  that  “the 
methodology  provides  a  systematic  way  of  thinking  about  and  dealing  with  a  future  containing 
fundamental  uncertainties  about  an  organization’s  ends”  (Dewar  1993,  pg.  57). 

Another  report  sponsored  by  the  United  States  Militaiy  Academy’s  Department  of  Systems 
Engineering  tried  to  attack  the  fiscal  problems  created  by  an  unconstrained  front-end.  The  purpose 
was  to  develop  methods  for  assessing  capabilities  of  alternative  force  stmctures  for  warfighting  and 
non-warfighting  missions.  This  methodology  also  assesses  joint  force  stmcture  based  upon 
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warfighting  requirements.  The  report  is  an  attempt  to  develop  a  methodology  that  will  provide  some 
analytical  rigor  to  the  process.  An  integer  programming  (IP)  model  is  used  to  make  force-unit  trade¬ 
offs,  using  Mission  Capability  Packages’  (MCP’s)  as  building  blocks.  “The  IP  model,  which  may 
eventually  evolve  to  a  generalized  mathematical  program,  determines  efficient  (i.e.  non-redundant  and 
effective)  force  mixes  to  accomplish  given  missions.  In  the  model,  MCP’s  are  defined  as  integrated 
slices  of  the  total  force  required  to  accomplish  assigned  missions”  (Farr  1994,  pg.  i).  The  Army  has 
tried  to  implement  this  model  in  the  WFLA  process  and  other  selective  areas.  Results  have  been 
inconclusive  to  date. 

Air  Combat  Command  has  recently  introduced  a  similar  tool  called  the  Modernization  Investment 
Plan  or  MIP.  Specifically,  it  is  a  goal  programming  tool  that  “links  investment  strategy  to  HHQ  and 
CAF  guidance;  analysis  of  our  needs;  and  capital  budgeting  activity.  It  includes  {sic}  decision  support 
system  as  part  of  the  process  to  aid  programmers.  It  contains  visible  program  interdependencies  and 
has  understandable  implications  of  iterations”  (Todd  1997).  It  has  a  mathematical  program  at  the 
heart  of  the  tool.  One  Air  Force  official  indicated  that  before  the  use  of  the  MIP,  ACC  was  hitting  the 
‘target’  about  5%  of  the  time.  With  the  MIP,  that  percentage  has  increased  dramatically  (ORiordan 
1998).  Ostensibly,  hitting  the  target  refers  to  the  way  ACC  allocated  its  resources.  These  cited 
percentages  meant  ACC  was  programming  and  budgeting  in  a  way  that  rarely  focused  those  scarce 
resources  on  the  real  issues.  Now,  that  ability  seems  to  have  improved  -  although  the  amount  of 
improvement  is  difficult  to  quantify  as  those  interviewed  expressed  a  range  of  answers  (from  25%  to 
75%).  The  true  impact  of  this  tool  remains  to  be  seen,  especially  with  the  variability  of  rack  and  stack 
lists  and  impacts  of  ‘commander’s  discretion’. 

Another  RAND  study  was  completed  to  assist  the  Air  Force  in  defining  a  new  concept  development 
framework  and  process  that  could  support  Air  Force  long  range  planning.  RAND  proposed  the 
creation  of  Concept  Operations  Groups  to  support  Air  Force  planning.  It  also  proposed  ideas  for  how 
the  Air  Force  might  proceed  with  institutionalizing  the  framework  and  process  (Lewis  1995).  This 
appears  to  be  a  further  derivation  of  the  TPIPT  process. 

Smith  proposes  conceptual  Changes  to  the  process.  There  are  seven  changes  that  he  suggests  to  the 
current  process.  First,  an  acquisition  professional  should  be  placed  on  the  combatant  commander’s 
staff  to  provide  the  CINC  with  more  acquisition  expertise.  Second,  the  CINC  should  have  the 
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authority  to  submit  a  Mission  Needs  Statement  directly  at  any  time,  not  just  during  times  of  conflict. 
Third,  mission  area  analyses  should  be  mandated  parts  of  after-action  reports  of  exercises  and 
conflicts.  Fourth,  commanders  should  be  able  to  advise  on  the  technology  plans  of  the  services. 
Fifth,  the  CINC’s  staff  should  be  allowed  to  prepare  or  coordinate  on  Analysis  of  Alternatives, 
Operational  Requirements  Documents,  and  Requirements  Correlation  Matrices.  Sixth,  test  schedules 
should  be  timed  to  coincide  with  exercises  so  that  concepts  can  be  exposed  to  approximated 
operational  experiences.  Seventh,  use  the  Joint  Warfighting  Capabilities  Assessment  QWCA)  forum  as 
the  foundation  for  Mission  Needs  Statements.  He  cites  the  experience  of  US  Special  Operations 
Command  (US  SOCOM),  with  acquisition  authority,  as  proof  that  these  changes  have  already  brought 
about  the  desired  effect  in  SOCOM  (Smith  1999). 
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Appendix  H  -  Why  the  current  air  Force  system  exists 

To  truly  gain  an  understanding  of  the  militaiy  system,  why  it  exists  in  the  form  it  does,  and  functions 
in  the  manner  it  does,  a  review  of  the  foundational  history  was  undertaken.  One  author  more  than  any 
other  has  helped  put  into  perspective  the  current  realities  of  the  system.  His  insights  are  as  applicable 
today  as  they  were  in  1953.  Mr.  I.B.  Holley,  an  Air  Force  historian,  wrote  three  papers  about  the 
acquisition  and  development  of  weapon  systems.  These  papers  were  based  on  his  experience  during 
the  last  18  months  of  World  War  II  and  a  few  years  afterward.  These  studies  had  a  common  theme 
that  led  to  the  publication  of  his  book.  He  observed  that  “the  pace  of  development  for  any  weapon 
system  during  the  between-war  years  is  chiefly  determined  by  the  extent  to  which  it’s  mission  or 
operational  function  is  known  and  defined.  When  there  is  no  effective  system  for  determining 
doctrine,  the  pace  of  development  is  necessarily  slow”  (I.  B.  Holley  1953,  pg.  vii).  Mr.  Holley 
succinctly  describes  the  situation  that  existed  in  the  early  history  of  the  US  Air  Force  and  actually  had 
its  roots  in  the  military  m  general. 

In  his  study  of  Air  Force  history  he  reveals  “three  specific  shortcoming{s}  in  the  procedure  for 
developing  new  weapons.  These  shortcomings  appear  to  have  been:  a  failure  to  adopt,  actively  and 
positively,  the  thesis  that  superior  arms  favor  victory;  a  failure  to  recognize  the  importance  of 
establishing  a  doarine  regarding  the  use  of  weapons;  and  a  failure  to  devise  effective  techniques  for 
recognizing  and  evaluating  potential  weapons  in  the  advances  of  science  and  technology”  (I.  B.  Holley 
1953,  pg.  10). 

Do  the  three  shortcomings  still  exist  in  the  military  today?  What  lessons  might  be  learned  from  this? 
This  author’s  judgement  maintains  the  first  shortcoming  no  longer  exists  in  the  Air  Force  today. 
Today’s  Air  Force  is  built  upon  the  premise  of  ‘superior  arms’  and/or  technology.  However,  the 
second  shortcoming  clearly  exists.  The  Air  Force  only  recently  (February  1997)  established  its 
Doarine  Center  at  Maxwell  AFB,  AL  (Michael  1999).  Although  nearly  40  doarinal  documents  have 
been  issued  by  the  center,  not  enough  time  has  elapsed  since  its  inception  to  quantify  the  impaa  of  the 
center  on  doarine  and  weapon  system  requirements/development  related  issues.  The  third 
shortcoming  also  exists.  Here  the  k^  is  in  the  term  'effeaive'.  As  a  recently  completed  study  of  the 
Air  Force  Requirements  Process  indicated:  the  Air  Force  "lacks  effeaive  guidance,  analysis,  and 
training,  causing  problems  with  linkages  to  other  core  processes,  resulting  in  an  unnecessarily 
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bureaucratic  process  that  is  ineffective  in  garnering  and  sustaining  program  support”  (HAF/XORD 
1999). 

The  link  between  doarine  and  new  technology  is  often  overlooked  because  the  existing  process  to 
develop  weapon  systems  does  not  include  it.  “It  is  not  surprising  that  the  problem  of  relating  doctrine 
to  technological  advance  in  weapons  received  only  belated  attention,  in  most  instances  long  after  the 
weapon  itself  had  become  available.  ...  The  greatest  stumbling  block  to  the  revision  of  doctrine  was 
probably  not  so  much  vested  interests  as  the  absence  of  a  system  for  analyzing  new  weapons  and  their 
relation  to  prevailing  concepts  of  utilizing  weapons”  (I.  B.  HoUey  1953,  pg.  15). 

Again,  the  recently  completed  study  of  the  Requirements  process  indicated  that  the  Concept  of 
Operations  or  the  Concept  of  Employment  was  the  single  most  important  part  of  defining  the  correct 
requirements  for  the  operation  of  the  system  (USAF/DXOR  1999). 

The  history  of  the  machine  gun,  tank,  and  gas  warfare  shows  “that  the  pace  at  which  weapons  develop 
is  determined  by  the  effectiveness  of  the  procedures  established  to  translate  ideas  into  weapons”  (I.  B. 
Holley  1953,  pg.  19).  This  simple  statement  knpUes  the  importance  of  'the  entire  process',  and  how  it 
drives  weapon  development. 

The  Army  had  two  faaors  in  the  Civil  War  era  that  contributed  to  failure  in  these  areas.  “The  first 
factor  was  the  apparent  inability  of  the  successive  authorities  to  establish  either  a  sound  organization 
or  effective  administrative  procedures  to  accomplish  the  desired  task.  The  second,  the  pressure  of  an 
obvious  need  for  standardization  in  opposition  to  the  continual  pace  of  technological  development”  (I. 
B.  Holley  1953,  pg.  19).  Do  these  problems  exist  in  the  Air  Force  today?  There  is  constant 
organizational  turbulence  and  changing  guidance.  Ever  since  Dr.  William  Perry  as  the  Under  Secretary 
of  the  Air  Force  for  Acquisition  launched  Acquisition  Reform  with  the  Mil-Standard  and  Mil-Spec 
reform  (in  1993),  there  has  been  almost  constant  churn  in  both  organizations  and  procedures. 
Furthermore,  ideas  such  as  platforming  and  design  reuse,  software  reuse,  etc.,  continue  to  gain 
momentum  and  importance,  although  their  impacts  to  organizations  and  procedures  remain 
unquantified. 

In  general,  the  “experience  of  the  {Army}  department  demonstrated  the  importance  of  establishiag  a 
concept  of  requirements,  the  military  characteristics  of  a  weapon,  before  beginning  development. 
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Similarly,  experience  had  shown  the  importance  of  differentiating  a  good  idea  from  the  failure  of  that 
idea  in  a  specific  application”  (I.  B.  Holley  1953,  pg.  21).  In  essence,  the  Air  Force  also  understands 
these  axioms  with  their  employment  of  a  Mission  Needs  Statement,  an  Operational  Requirements 
document  (with  accompanying  Concept  of  Employment),  and  also  a  formal  Analyses  of  Alternatives. 

Air  applications  in  WWl  were  interesting  to  note.  The  “Chief  of  the  Air  Service,  AEF^'’,  emphasized 
the  critical  importance  of  progressive  development  of  design  in  maintaining  a  force  of  aircraft  superior 
to  that  of  the  enemy  on  the  front.  An  aircraft,  which  dominated  the  air  one  day,  he  reported,  might  be 
“totally  obsolete”  six  months  later.  Superiority  in  the  air,  he  concluded,  could  be  maintained  only  by 
constant  initiative,  encouraging  inventions  leading  to  new  types,  and,  where  necessary,  abandoning 
unsuccessful  models  even  after  they  have  been  brought  into  production”  (I.  B.  Holley  1953,  pg.  152). 
“In  the  final  analysis,  doctrine,  or  the  accepted  concept  of  the  mission  to  be  performed  by  the  aerial 
weapon,  would  inevitably  determine  the  direction  of  development” (I.  B.  Holley  1953,  pg.  156). 

“A  somewhat  closer  study  of  military  history  shows  that  new  and  more  effective  weapons  have 
generally  been  adopted  only  slowly  in  spite  of  their  obvious  advantage.  World  War  1  emphasized  the 
necessity  for  a  conscious  recognition  of  the  need  for  both  superior  weapons  and  doctrines  to  ensure 
maximum  exploitation  of  their  full  potential.  As  a  corollary  to  these  two  requirements,  the  war 
pointed  up  the  need  for  administrative  agencies  to  ensure  their  fulfillment  once  they  have  been 
recognized  as  requirements”  (I.  B.  Holley  1953,  pg.  175). 

Therefore,  what  are  the  main  issues?  Slow  adaptation  of  newer  and  better  weapons  despite  their 
obvious  advantages.  Doctrine  is  essential  to  successful  system  development.  A  Process  is  required  to 
develop  requirements  and  systems.  The  concept  must  be  in  place  with  accompanying  doctrine  before 
beginning  development.  Sufficient  analysis  must  take  place  to  understand  all  of  the  variations  and 
their  tradeoffs.  What  is  the  importance  of  these  issues?  The  respective  lack  thereof  leads  to  the 
development  of  performance-driven  “gold-plated”  specifications. 

Predecessor  to  the  MPP 

The  Air  Force  has  tried  to  address  all  of  the  issues  above.  The  MPP  is  just  one  of  the  latest  examples 
of  1.  Emphasizing  the  importance  of  up-front  planning,  and  2.  Trying  to  bring  formality  and 
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repeatability  into  the  process.  Further  reasons  for  its  existence  as  well  as  its  development  are  discussed 
below. 


Prior  to  the  existence  of  the  Air  Force’s  MPP,  the  process  in  place  was  known  as  the  Vanguard 
process  (RomaneUi  1998).  There  were  some  major  differences  between  it  and  the  present-day  MPP. 
Chief  among  these  differences  was  that  the  Air  Force’s  Acquisition  Community  determined  needs  and 
requirements  based  upon  inputs  from  the  Warfighter  Communities.  It  sought  to  elicit  the  right  kind 
of  requirements  out  of  users.  Because  of  this  approach,  Vanguard  was  known  as  “requirements-puU”. 
In  1981  it  underwent  a  major  change  to  relate  user-defined  requirements  into  an  operational  capability, 
and  integrating  technology  planning  into  the  overall  process  by  providing  a  focus  for  technology 
thrusts  and  transition  plans.  Vanguard  was  divided  into  10  separate  mission  areas  so  that  it  would  align 
with  the  mission  areas  used  at  Fleadquarters  United  States  Air  Force  (HQ  USAF)  for  budgeting 
purposes  (Weishoff  1990).  In  its  original  concept,  “Vanguard  needed  to  do  three  things  well: 

□  It  should  analyze  available  capabilities  and  compare  them  with  what  is  required. 

□  It  should  synthesize  programs  to  make  up  the  difference. 

□  It  should  provide  a  means  for  integrating  these  programs  into  a  cohesive,  meaningful  whole,  which 
is  tied  to  the  real  world  of  equipment  and  operations”  (Weishoff  1990). 


Before  the  demise  of  the  Vanguard  process  in  1988,  its  objective  was  to  help  the  MAJCOMs  better 
allocate  their  resources  in  the  POM  years  by  helping  them  develop  a  fiscally  constrained  20-year 
roadmap  of  weapon  system  concepts  and  the  Science  &  Technology  (S&T)  investment  program.  But 
the  system  could  not  do  this  automatically.  The  MAJCOM  had  to  take  the  Vanguard  information  and 
use  it  to  develop  the  fiscally  constrained  roadmap.  “Many  seasoned  Air  Staff  officers  thought  this  was 
the  key  to  determining  the  success  of  the  new  long-range  planning  system,  actually  influencing  how  the 
limited  resources  were  allocated  among  competing  requirements  during  the  annual  POM  battle” 
(Smith  as  cited  by  Weishoff  1990,  pg.  76).  Unfortunately,  constrained  financial  planning  did  not  occur. 
It  simply  could  not  happen.  Two  earlier  AFfU^  studies  cited  by  Weishoff  “found  that  the  most 
common  difficulties  with  strategic  planning  were  insufficient  time,  unpredictable  political  environment, 
inadequately  defined  objectives,  inexperienced  managers,  very  difficult  cognitive  activity, 
...  {which,}...  makes  evident  the  uncertainty  of  future  events,  reduces  perceived  freedom  of  action,  is 
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computationally  tedious,  and  plans  are  often  made  and  then  ignored"  (Corey  and  Shofner,  as 
referenced  by  Weishoff  1990,  pg.  56).  The  Vanguard  process  failed  because  it  fell  victim  to  most  of 
the  above  factors  (Weishoff  1990). 

The  MPP  as  it  exists  today  (and  as  discussed  in  the  previous  chapter),  is  run  and  executed  by  the 
MAJCOM  with  assistance  from  the  Acquisition  Community.  This  is  a  key  difference  between  the 
MPP  and  the  Vanguard  Process.  Part  of  this  change  was  to  eliminate  the  stereotypical  image  of 
'pocket-protector  ‘techies”  driving  technological-based  solutions.  Additionally,  since  this  process 
needed  to  interface  with  the  Air  Force  Operational  Requirements  community  (also  led  and  executed 
by  the  operational  users),  it  was  thought  to  be  a  rational  improvement  to  the  existing  arrangements. 
Furthermore,  it  was  important  that  those  individuals  writing  the  requirements  understood  what  the 
concepts  presented  by  the  MPP  really  represented. 

Common  feamres  between  Vanguard  and  the  MPP  include  their  relationship  to  the  PPBS.  “A  set  of 
fiscally  unconstrained  alternative  weapon  systems  concepts  was  then  proposed  to  correct  each 
deficiency.  This  initial  unconstrained  investment  program  usually  exceeded  the  projected  available 
financial  resources.  ...  Since  the  POM  years  could  not  be  affected,  this  created  a  bow  wave  effect 
starting  the  year  after  the  POM  and  continuing  throughout  the  planning  horizon.  The  forecast  was 
accomplished  by  theoretically  deleting,  cutting,  stretching,  or  slipping  individual  programs  within  each 
mission  area”  (Weishoff  1990,  pg.  42).  The  MPP  captures  this  unconstrained  look  with  the  Mission 
Area  Plan. 

Although,  the  MPP  replaced  Vanguard  largely  due  to  the  perceived  benefits  over  the  Vanguard 
process,  one  element  of  the  Vanguard  process  was  incorporated  into  the  follow-on  MPP.  This  is  the 
use  of  the  Technical  Planning  Integrated  Produa  Team  or  TPIPT. 

Additionally,  legislation  changed  the  relationship  between  operators  and  the  planning  community  with 
help  from  acquisition  professionals.  “Goldwater-Nichols  played  a  major  role  in  tipping  the  scale  for 
the  operators  over  the  innovators  by  empowering  the  fleet  Commanders-in-Chief  in  the  future  of 
requirements  generation.  This  was  realized  by  the  creation  of  the  Joint  Requirements  Oversight 
Council  (JROC)  and  later  the  Air  Force  Requirements  Oversight  Council  (AFROC).  Additionally,  this 
legislation  created  the  use  of  the  Chairman’s  Program  Assessment,  a  formal  communication  to  the 
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Secretary  of  Defense  from  the  Joint  Chief  of  Staff  where  the  services  were  deficient  in  meeting  the 
requirements  of  the  CEMCs.  Finally,  this  legislation  created  the  Integrated  Program  Priority  list 
(IPPL)  for  the  CINCs.  So  far,  these  efforts  have  been  met  with  mked  results  (Smith  1999).  In  his 
CNO  staff  meeting.  Admiral  Kelso  once  astutely  addressed  the  question  of  who  sets  the  technology 
program  requirements.  “If  you  ask  the  fleet  what  they  want,”  he  said,  “they  will  tell  you  exactly  what’s 
wrong  with  the  equipment  you’ve  given  them  and  tell  you  how  to  fix  it””  (Momiyama  1998).^*  Recent 
developments  is  this  area  include  the  ‘deputi2ation’  of  the  Atlantic  Commander  (A  Naval  Admiral)  by 
the  Component  Commanders  to  advocate  Commander-in-Chief  (CINC)  priorities  to  the  JROC  (CJCS 
1999). 

Predecessor  to  the  PPBS 

Prior  to  the  introduction  of  the  PPBS  in  1961,  the  three  military  services  created  their  budget 
submissions  independent  from  each  other.  For  the  most  part,  the  services  stayed  within  their 
traditional  roles  and  missions.  However,  there  were  many  problems  that  resulted  from  this  approach. 
For  instance,  there  were  many  examples  of  weapon  duplication,  little  understanding  of  joint  concepts 
and  requirements,  and  very  divergent  views  on  the  nation’s  defense  needs  and  strategy  (Salazar  1996). 

A  Joint  DoD  and  GAO  study  identified  several  flaws  in  the  current  system.  The  result  was  the 
introduaion  of  a  centralized  system  that  sought  to  overcome  those  drawbacks  (Salazar  1996).  The 
services  were  to  plan  weapon  system  procurements  in  advance.  The  new  process  divided  the  overall 
defense  budget  into  ten  major  force  programs  containing  Program  Elements  (PEs)  that  were  the  basic 
elements  (aircraft,  ships,  tanks,  etc.)  of  the  DoD  budget  (Salazar  1996).  The  planning  was  done  within 
the  Five  Year  Defense  Program  (FYDP),  now  called  the  Future  Years  Defense  Program  because  it 
covers  six  years  (execution  year  and  five  planning  years)  (Salazar  1996). 

Since  the  initial  introduaion  of  the  PPBS,  it  has  been  in  a  constant  state  of  evolution.  Most  of  these 
changes  reflea  the  different  personalities  of  the  Defense  Secretary,  who  exercises  control  over  the 
PPBS.  The  Joint  Chief  of  Staff  have  had  varying  roles  and  degrees  of  influence  throughout  the 
evolution  of  the  process,  with  the  latest  iteration  placing  more  control  in  their  hands  (Salazar  1996). 


58  December  7,  1998  issue  of  Aviation  Week  magazine  contains  information  about  the  very  recent  strengthening  of  the  CINCs  in 
determining  requirements.  The  outcome  of  this  action  remains  to  be  seen. 
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Predecessor  to  Requirements  System 

The  advent  of  the  JRC)C  and  other  senior  decision  fomms  is  a  relatively  recent  phenomenon.  These 
have  only  been  present  in  the  existing  system  since  the  early  1980s  (Salazar  1996).  Their  formation 
came  as  the  result  of  pressures  to  reform  the  way  the  military  conduaed  its  acquisition  and 
requirements  processes.  These  pressures  were  in  part  due  to  the  1980  Iranian  Hostage  rescue  debacle 
and  also  due  to  the  increasing  costs  of  weapon  systems  (Salazar  1996). 

The  advent  of  a  formal  Requirements  Process  emerged  only  after  the  introduction  of  the  PPBS.  Prior 
to  this  time,  the  informal  process  in  place  was  to  first,  identify  an  existing  need,  second,  establish  the 
requirement,  and  third,  obtain  approval  for  the  acquisition  from  the  appropriate  acquisition  authority 
(GAO  1974).  Since  1961,  the  acquisition  system  has  been  stmctured  and  various  documents  have 
been  used  to  fulfill  the  three  steps  listed  above  (Lebovic  1996).  In  all  of  the  services,  these  documents 
have  had  different  names  but  have  essentialfy  served  the  same  purposes.  Today’s  Mission  Need 
Statement  in  the  Air  Force  was  a  Statement  of  Need.  Today’s  Operational  Requirements  Document 
in  the  Air  Force  was  a  Required  Operational  Capability  (GAO  1974).  Furthermore,  the  process  was 
not  as  rigid  as  it  is  today.  For  instance,  there  were  no  Requirements  Documents  available  for  the  A- 10 
aircraft  after  it  had  been  fielded  (in  1974)  (GAO  1974).  Prior  to  1969,  Requirements  Documents  were 
only  generated  after  a  decision  to  develop  a  weapon  (Lebovic  1996).  1969  marked  the  introduction  of 
the  current  Acquisition  System  of  today  by  Secretary  of  Defense  Packard.  Additional  changes  have 
been  made  to  the  system  since  that  time,  like  the  addition  of  Milestone  0  in  1977  (Lebovic  1996). 
Additionally,  a  GAO  report  introduced  for  the  first  time  the  notion  of  ’’backfill”  in  1974.  “That  is,  the 
documents  that  currently  record  the  flow  of  the  process  for  an  acquisition  were  prepared  after  the  fact. 
We  believe  this  is  often  the  case  since  decisions  are  usually  made  based  upon  analysis,  studies,  and  the 
other  influences,  and  then  documented”  (GAO  1974).  The  same  report  also  indicated  that  each 
system  followed  its  own  process  and  not  a  formally  defined  one  (GAO  1974).  The  guidance, 
regulations,  and  instructions  for  the  process  defined  a  framework  whereby  Requirements  could  be 
identified,  established,  and  approved.  Since  then,  the  notion  of  “backfilling”,  and  using  separate 
processes  for  each  system’s  requirements  has  fallen  into  disfavor  and  the  current  Requirements 
Generation  System  expresses  these  sentiments  as  a  result. 
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Appendix  I  -  Requirements  Documents  Necessary  to  Support  Modifications 


Production  Status 

Dollar  Amount 

Requirements 

Document 

Approval  Authority 

Pre-MS  III 

Any  Amount 

ORD  Update  or  ORD 
Revision 

Appropriate  MDA 

In-Production  (Post- 
MS  III) 

Any  Amount 

ORD  Annex  or 

Revision 

Appropriate  MDA 

Out-of-Production 

>$65M  in  procurement 
OR>$14Min 

Research, 

Development,  Test  & 
Evaluation  (RDT&E) 

MNS  to  document 
new  deficiency 

JROCorCSAF 
pending  potential 

ACAT  designation 

Out-of -Production 

$10  -  $65M  in 
procurement  OR  $10  - 
$14M  In  RDT&E 

=:->:-=:-AF  Form  1067  with 
Requirements 
Correlation  Matrix 
(RCM)  &  transmittal 
letter 

HQUSAF/XOR 
(Requirements  Point  of 
Contact  in  the 

Pentagon) 

Out-of-Produaion 

<$10M  in  procurement 
OR<$10Min 

RDT&E 

AF  Form  1067 

MAJCOM 

NOTE:  AH  costs  in  this  figure  are  FY96  Constant  year  dollars 

NOTE:  Modification  to  an  out-of-production  system  requires  validation  -  DoD  5000.2-R 
’'■“'•“'■NOTE:  AF  Form  1067  is  being  used  in  lieu  of  requirements  documentation  as  required  by 
AFPDlO-6.  (USAF/DXOR 1999,  pg.  25) 
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Appendix  J  -  Flowcharts  on  MNS,  CRD,  and  ORD  development 


Figure  82.  Overall  Requirements  Process  Flow 
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Develop  Mission  Need  1-1 -1-1-1 


Figure  83.  Air  Force  Mission  Need  Statement  Process  Flow 


Develop  Capstone  Requirements  Document  1-2-1 -1-1 


Figure  84.  Air  Force  Capstone  Requirements  Document  Process  Flow 


Develop  Operational  Requirements  Document  I-2-2-1-1 


Figure  85.  Air  Force  Operational  Requirements  Document  Process  Flow 


Appendix  K  -  Overall  view  of  process  from  AFMC  perspective 


Figure  86.  First  slide  of  AFMC  View  of  Process 


oo 

On 

ON 


Figure  87.  Second  Slide  of  AFMC  View  of  Process 


Figure  88.  Third  Slide  of  AFMC  View  of  Process 
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